Last week, Terah, Jacob, and I boarded a train in Kansas. We were bound for Los Angeles, then would go up the coast of California, eventually winding up in Portland for OSCON.

Our first train was the Southwest Chief out to LA.



Jacob had a great time on the train. This is a picture of Jacob and Terah in our sleeping car room. Jacob slept in his carseat at night and played with us during the day. See all recent photos of Jacob.

We had the option to get off the train for a few minutes in La Junta, CO. I took some photos trackside.



Here's Jacob enjoying the lounge car. There were dozens of Boy Scouts on our train, heading to the Boy Scout camp near Raton, NM. Many of them hung out in the lounge car, so Jacob had plenty to watch and keep him entertained.



The lounge car has wrap-around windows. We got an expansive view of the Rockies on the first day of our trip, and of the California desert on the second. This route really gives you a feeling of being alone sometimes. There are times where you can look out the window, and as far as you can see, there is no evidence of people or civilization.

Here's a picture out the lounge car, looking at the train as it rounded a curve.



The lounge car was in the middle of the train, so the train really was longer than it might appear here.

We had a bit of an adventure in Lamy, NM. Apparently a terminal cancer patient was riding the train, and died in the night. We were held up for about 2 hours for authorities to arrive, perform their investigation, etc.

While we were there, passengers could get off the train and look around. I took a few photos there.



This is a photo looking towards the front of the Chief. It uses bi-level cars, so every car has an upstairs and a downstairs.

Just outside the Lamy station is an old dining car. It is now a stationary restaurant. The restaurant had closed just before we arrived, but they let me in to take a few quick photos anyway.



Just past Albuquerque, one of the two locomotives on our train failed. That meant that, combined with the delay at Lamy, we were more than 3 hours late into Los Angeles. That, in turn, meant that we missed our connection to the Coast Starlight. So the new plan was to take a bus to Bakersfield, then the San Joaquin train to Sacramento, where we could catch up with the Coast Starlight and get to Portland as scheduled.



Jacob really enjoyed the Bakersfield train station. I carried him up to the stone walls, which he enjoyed exploring with his hands.



This is the Bakersfield station. It's a nice building. But their large metal sign reads "To trains and busses." Someday I will forget about them misspelling "buses" on a large metal sign.

I've got two more pictures of Jacob at Bakersfield that you'd enjoy: one, two. He sure was a popular baby. We got countless compliments from strangers, and he got even more smiles and greetings from people. Even when he was fussy, people kept saying what a good baby he was. We were a little surprised at that. A few people even found his cry to be cute and funny!



One of the nice side-effects of missing our connection was seeing the grand old Sacramento train station. A beautifully-decorated building. We were there until about 12:30AM because the Coast Starlight had been delayed as well.

Terah saw a sign out the door saying "Quiznos: Now Open." I figured that meant that the store was open, not that the place was open late into the night, but she wanted to check. She stepped out and then back in again. "As soon as I got out, homeless people started yelling at me! Plus the store wasn't open," she reported.



On the Coast Starlight, we discovered the absolutely stunning Pacific Parlour Car. These cars were originally built in the 1950s for the Santa Fe railroad, and have been renovated and restored by Amtrak for service on the Coast Starlight. That's the only train where they run, and they are available only to first-class passengers.

I noticed stairs going to the lower level of the Parlour, and was curious what was down there. So I went down to check it out, and it is a small (18 seats, I think) theater!



We sat down there for awhile and talked to some of the other people.

The view from the Coast Starlight was amazing. The trip through the mountains was particularly nice. We saw mountains from the distance, up close, and at some points could look out our window directly down into a deep valley below. There were lakes, waterfalls, and little creeks all along.



And finally, this is the grand Portland train station. Still an active station and a sight to see, though not as nice as Kansas City's.

So that's the trip to Portland. More to come on the convention and the city itself.

I was in New York this past week meeting with a bunch of Sun customers and speaking at several Solaris related events. On Wednesday, just before 6pm, we were on a conference call in the Sun office at 101 Park Ave. when we heard a noise that sounded like thunder, and the whole building shook. When the noise didn’t stop, we stepped into the hallway and looked out the window to see 41st St. filled with what appeared to be smoke, debris hitting and nearly breaking the window, and people running down the street en masse. We filed down the stairwell and emerged into a scene straight from 9/11—shocked looking men in suits covered in a layer of brown debris, masses of people hurrying down 40th St. as fast as they could dashing across streets without regard for the traffic, cars honking their horns trying to get away through the throng, sirens blaring, cell phones not working, policemen doing their best to maintain control, people crying and holding each other, necks craning to see a plume of “smoke” rising into the sky high enough to obscure the Chrysler Buidling, and that awful roar that just wouldn’t stop. Of course, the “smoke” turned out to be steam, and the roar was the steam blasting out of an enormous crater on 41st that turned out to be just outside that window. But at the time, no one had any idea what was going on, and with lack of information comes speculation: It’s rush hour, they’ve blown up Grand Central Station, what’s next and when? It took a good hour before anyone knew it was just a steam pipe and nothing sinister. All in all, it was a pretty extraordinary experience that’s going to stick with me for a long time.

I very much like the satire news site bbspot.com. Besides some very good original stuff (news such as Number of Linux Distributions Surpasses Number of Users and top-11-lists such as Signs You Need to Clean Your Keyboard ), Brian Briggs regulary features so called bbloopers, funny typos and content-advertisement combinations from across the web. Although I d prefer he woudn t clutter his page with these (and those imported comics), or at least provide a feed without them, I submitted one I recently stumbled upon: The secret of Black Soap.

I just released new version of Gammu. This release brings lots of changes in AT phones driver, so please report any regressions from previous releases! Also experimental support for notes over OBEX has been added, but I din't have phone to actually test these, so again testing is very welcome! Full list of changes:

• Introduced more generic parsing of AT replies, please report any regressions with it!
• Improved support for Samsung phones.
• Support for reading network name from AT phones.
• Add deletememory command line.
• Experimental support for notes over OBEX.
• Man page is now partially autogenerated from online help.
• Elson compatibility, thanks to Bernd Feige.
• Fix UCS detection, thanks to Bernd Feige.

DemoCamp Montr al 3 is happening tomorrow. We're going to be at the SAT from 18:30 to 20:30, holding demonstrations on a whole range of different topics. Why DemoCamp? Well, Montrealers are some of the most creative people I know and they've got plenty of things to show and tell. DemoCamp is like a big gathering of creative minds who get to watch fifteen-minute presentations on anything. And since all you can do is demo: no slides, no gimmicks, then you actually get to see real stuff doing real things. I'm going to be there to show you how to make a counterclock. You know, the opposite of a clock that goes clockwise. Along the way, I'll do a little explaining of electricity, timekeeping, and motors. I just have to remember to buy a clock today. :P Come on, it'll be fun! DmoCamp Montr al 3
Tuesday, 24 July 2007
18:30 20:30
Societ des arts technologiques
1195 boul. St-Laurent
Free admission ( Sign up Facebook Upcoming Google Maps )

Ian, I am not sure that “good package management” is a real selling point for anyone but system administrators. Home users do not care, as there is not that much difference between double-clicking an executable (that pops up a window, asks a few questions and then installs the software) and selecting a check-box in a list and clicking “apply” (followed by window, questions, etc.). In a business setting the users usually do not have permission to install software anyway, so they could not care less how it was installed, the only thing important is that it is there. In my opinion, the single technology that has had the most impact would be COM, the “Component Object Model”, because this is what the ISVs want: an easy way to define a (binary) interface that will allow components from different vendors to work together, ideally in the same virtual address space for maximum efficiency. The registry provides the necessary lookup functionality, so that you can construct an object of a given type by giving its class name or GUID to CoCreateInstance, and you get something back that provides the interfaces that this class implements, which is either the object directly or an RPC proxy. The latter happens, for example, when a multithreaded application wants to call methods in an object that is not threadsafe (COM will then serialize the calls) or when the object is provided by a system service (where we have dbus). The fact that the only thing you can rely on is the defined interface (a set of methods and data objects that map to getter/setter methods) makes it necessary to define the interface first and invest lots of Interfaces become immutable as soon as they are published, incompatible changes need a new interface name (that's where all the interface names ending in …2 or …3 come from). Under Linux, the closest thing is GNOME and their use of CORBA. If you were to write an application that runs within the GNOME framework, and if you wanted third party vendors to be able to plug into it, then you would probably publish an IDL file for it. Lots of “if”s there. Licensing is also an issue here. One thing the GPL fails to address, even in version 3, is the integration of components without linking into the same address space (which ORBit never does IIRC). Technically, the component provider and the component user communicate via sockets using a well-known protocol, so the component user is not bound by the GPL; the only thing that could be argued is that the IDL file defining the interface would be GPLd (although most jurisdictions consider interfaces as not copyrightable and/or permit “reengineering” for interoperability purposes). Some people might consider this “cheating” around the GPL, as any GPL'd program or library providing components could be used freely by any closed source application as long as the source code to the GPL'd portions was made available. Last (but not least) it is a matter of developer motivation. Third party vendors are, for most of us, not our target audience, and properly supporting them is going to be quite a bit of work. I've written about mixing different C libraries in the same executable image before, as a “nice to have” item. For components that should share the same image, like COM does, it is an absolute must, and COM goes to great lengths to make sure this actually works. For example, allocating memory that is to be passed to a COM method must be allocated using midl_user_alloc() from the RTC DLL and freed using midl_user_free() from the same; as this is a system library and compiler vendors are forbidden from bringing their own, everyone uses the same allocator pair (that internally just calls malloc() and free() from the Microsoft C library, but that is an implementation detail you are not supposed to know). On the Linux side, people do not care much about matching allocator functions, because in essence it all ends up in glibc's malloc()/free() anyway. When glib introduced their own allocators and started using them for their own structures, a number of applications started crashing unless you set a certain environment variable that told glib to pass everything through to glibc. Personally, I've spent the last days compiling toolchains in order to provide compiler packages that work “out of the box” on at least Debian etch, lenny and sid, and Ubuntu dapper, edgy, feisty and gutsy. Right now, I feel a lot like shipping statically linked binaries. Where Windows has mostly gotten out of the “DLL hell”, Linux has built its own variant of it:

The Windows DLL hell

is a hot place. Everyone is bringing their own grill lighter they believe does not cause cancer, starts a small fire and begins to roast marshmallows. The problem there is that the floor is covered with a sticky mixture of lighter fluid and everything is burning.

The Linux DLL hell

on the contrary is freezing cold. It has small isolated fires where a few friends are sitting, and they suddenly decide to move on and pour water over the fire and your marshmallows without asking first. Getting into a group is difficult, and if you manage it, all it means is that you are told to pick up your marshmallows before they extinguish the fire.

At this point, I'm going to be comment- and trackback-whoring; instead of answering the obvious question, I'm going to leave it open: Would a COM-style componentization model work in the Linux world, and attract software vendors, provided we can put out stable APIs and support them properly, or is that a red herring?

Here’s an interesting piece in the Washington Post about what might happen when the US withdraws from Iraq. I regret not blogging before the war started. It would have been good if I could have pointed to a blog post predicting the same thing before the invasion took place. I’ve always thought that the two possibilities for Iraq were for the country to be partitioned (which would be likely to weaken Turkey and strengthen Iran and thus be avoided by the US if possible) or run by an absolute despot.

Share This

Hey folks, we released some minutes ago finally Debian-Edu/Skolelinux 3.0r0 “Terra” which is based on Debian 4.0 with some modifications to work out-of-the box. Here are the releasenotes: Oslo - July 22., 2007 Skolelinux 3.0 is ready. This is an community release with comprehensive support from regional and national projects in Germany, Spain, France, Greece and Norway. The Skolelinux project is now a part of Debian under the name Debian-Edu. Several other projects have made additional functionality to Skolelinux tailored for national needs. Skolelinux now supports more than 50 countries.

Whats new in Skolelinux 3.0:

• based on Debian 4.0 “etch” and therefore compatible to LSB 3.1, using kernel 2.6.18 and KDE 3.5.5
• Full support for networked Thin clients, LowFat (diskless) clients, Workstations and Laptops. With the LowFat clients users got full PC functionality with extremely low maintenance cost. The use of LowFat clients gives full support for sound, video, USB memory stick’s and DVDs without the need for a local installation.
• Skolelinux now got more than 80 applications selected for pedagogic uses, supporting more than 50 languages. Many new applications are introduced in addition to popular classic as GCompris, KDE-Edu, Iceweasel (unbranded version of Firefox) and OpenOffice.org.
• Installation is a breeze: Both the installation and source code for all software are now distributed on a single DVD now supporting three different processor platforms as i386, PowerPC and AMD64. This makes it more easy to choose hardware, and to study the recipes behind the software. Those interested can exercise their freedom to learn, participate and share knowledge more easily. Installation CDs are also available, but requires a working Internet connection for installation.

About Skolelinux Skolelinux is a complete tailored software solution for the needs of any educational institution or school. It is a ready computer system were the school does not need to piece together the components. Skolelinux is the result of the work of the Debian Edu project and Debian Edu is an official Debian subproject. It is installed in a great number of schools in Norway, Germany, France and other countries. Municipalities and Commercial Service Providers run Skolelinux across multiple schools, operated and maintained centrally. Service providers report that the “lowfat clients” require half the maintenance cost of other desktop alternatives. The next milestone of Skolelinux development will be to merge the Debian-based LinEx distro into Debian Edu. Currently LinEx is used by more than 250,000 students and public employees in the region of Extremadura in Spain.

In depth “Lowfat clients” is also known as Diskless workstations. They run applications locally on the client. All software comes from the server instead of locally from the client hard drive. Recommended minimum requirement for client machines is > 256 MB RAM and 800 MHz CPU. Skolelinux now got improved tools for system surveillance and maintenance. Roadmap for next merging of LinEx and Debian-Edu: * http://wiki.debian.org/DebianEdu/LinEx2DebianEdu-Roadmap Please note that the documentation for the 3.0 Terra release is only available in English at the moment and contains some rough edges. We have considered releasing before the end of the summer holidays more important and we will fix those rough edges in the coming weeks, when we also expect more translations to show up. Those fixes will be included in the upcoming 3.0 r1 release.

Don Marti writes about the idea of setting a Troll-bit on forum posts such that every reply would also be flagged. I’ve been thinking about how to solve such issues for mailing lists. I think that the way to do this is to create a new list for every contentious topic and automatically subscribe everyone who posted to the thread after the messages that were flagged as being too far off-topic. After that time anyone who tries to post to the main list with a matching subject or a header indicating that the message is a reply to an off-topic message would have their message redirected to the new list - and they would be automatically subscribed. This would keep the off-topic messages away from the main list and also serve as a minor dis-incentive for people to post to threads that start going off-topic as most people won’t want to be subscribed to the new list for off-topic messages. However such messages would still be archived (in a different section) so if the moderator mis-classified a thread it could still be reviewed by other people. Also when moderating such threads it would be interesting to experiment with consensus moderation of posts. If N subscribers of the list who post regularly use a web form to indicate that a certain post was too far off-topic and should spawn a new list then that could happen. I agree with Joey Hess’ rant about forums, so solving a problem for forums is not of interest to me, but hacking on a list server is something that I would do if I had enough spare time.

Share This

What’s the single biggest advancement Linux has brought to the industry? It’s an interesting question, and one that in my opinion has a very simple answer: Package management—or, more specifically, the ability to install and upgrade software over the network in a seamlessly integrated fashion—along with the distributed development model package management enabled. It used to be that operating systems were big, monolithic products, and applications were big, monolithic products you put on top of them. If you wanted to deploy, say, a web application, you sourced the middleware stack (which itself was probably several big products too), you sourced the operating system, and you (often painfully) had to integrate the two yourself (or pay a big company lots of money to do it for you). These days, you increasingly just “apt-get install whatever“. In this world, where does the operating system end and the application begin? The line is increasingly blurred—for when applications are deployed using an OS facility, seamlessly integrated with the OS itself, is the result an application or a feature of the operating system? In fact, in a very real way, all software looks to become part of the operating system—or, at least, this has certainly been the trend in the Linux world. What does this shift mean to the industry? For one thing, those of us that build operating systems as monolithic products have to change—it’s what users expect, and with a componentized operating system rather than a wad of stuff, it becomes far easier to push new innovations out into the marketplace and generally evolve the OS over time. Indeed, refashioning Solaris as a “distro” is the essence of Project Indiana—and package management is the key technology that will hold it all together. So, the next time you read about how Project Indiana aims to make Solaris more “Linux-like”, keep in mind that what we’re actually “copying” is the distro model, not Linux itself—which, after all, is a kernel, and has nothing to do with the package management and so forth the distros (you know, like Debian) built above it. This, better than anything else, highlights the opportunity for Solaris: What people really know when they say they know “Linux” is the environment that exists around the Linux kernel—the distro—all of which Solaris can deliver, and more.

The recent announcement that sparc32 is to be retired seems to be regretted by many. Various suggestions on what should or could be done have been put forth. Here's mine: let's at least create some minimal project infrastructure for a (hypothetical) sparc32 port. So, there now exists a sparc32 Wiki page and a sparc32 mailing list. All that remains is people who actually do stuff.

Half a year ago Tolimar blogged about a book called Tuareg, which sounded very interesting, so I asked him to lend it to me, which he did in Edinburgh. Last night, I decided to read a bit, to calm down before going to sleep. At 5am I had finished the book... :) And I must say, I really really liked it, including those two last chapters Tolimar didnt like :) Not exactly a happy end, but IMO a very good end. Recommended to read.

In answer to zobel's post, here is how to fight efficiently against those nasty spams. Well, there is a wonderful tool, called clamav that you know already for sure. What is less known is that there are people that have had the idea to use clamav to fight spams as well. They provide constantly renewed spam signatures that fight against the jpgs/gifs/... that are too many those days. I use this script twice a day to update my signatures, and it works well. I use this setup on a medium sized mail server with excellent results, here are the numbers for the last 30 days. The mail server had:

 2.357.038 connections attempts
 1.841.425 mails have been greylisted[]
 ---
   510.193 mails have been rejected
   238.869 of those thanks to clamav (~50%) 
 ---
   502.580 mails have been accepted for delivery
 1.564.130 mails have been delivered to users

As you can see, on 4 mails that are considered for delivery (after the greylisting), 1 is rejected thanks to clamav. That's 25% of the incoming mails that get simply dropped, and that has almost 0 false positives^[2]. Another note about greylisting: a quick reader could think that 1.8M - (2.3M - 0.5M - 0.5M) ~= 0.5M of mails are greylisted for nothing. That's not the case at all, the 2.3M are connection attempts. And we have some SMTPs that we talk to a lot (as it's the mail server of the Alumni of my school, we talk to the school MX a lot e.g.) and some of the connections carry up to dozens of mail on a regular basis. Our estimation is that in a regular day, greylisted mails that are submitted again are around the thousands, meaning some dozens of thousands a month, which is ridiculously small. And among them, sadly, most are still spams. These good ratios exists because we use conditional greylisting: we greylist IPs that look suspcicious only. But I already talked about that, and it's not really the matter of this post.

There was a very strong earthquake in Niigata, second in twoyears.It's not too usual to have two consecutiveearthquakes this size.People in Tokyo are mostly fine, but we expect electricityproblems this summer. We rely on nuclear plants in thatregion to supply our electricity.

Currently, there are two kinds of "special" source packages in use in the embedded world:

the toolchain package

needs a third system type and builds differently for each. We currently handle that with a script with intrinsic knowledge about the package being built

the target runtime

is target, but not host specific, and is built from a regular package with dpkg-cross

The plan for tonight is to work towards autobuildability.

The ABC reports that an oil shortage is predicted soon. The International Energy Agency predicts that oil supply problems will start within the next five years. Oil production has been dropping over the last two years (we have passed the “peak oil” point) and demand is steadily increasing. Regardless of wars oil prices will increase significantly in the near future. According to the Australian Bureau of Statistics the average age of Australian cars was 10.7 years at the end of 1998. So the vast majority of the current fuel-hungry cars on Australian roads will still be in use in five years time - if the owners can afford them. The government needs to start providing tax incentives for fuel efficient cars and to end tax incentives for inefficient cars. Currently 4WD vehicles have reduced taxes and the tax deduction for a business car is based on the engine size (get a less efficient car and get a bigger tax deduction). The government claims to be protecting the economy (at the expense of the environment). But with the way things currently work the economy will be destroyed in less than five years. Even though the government cares little for the environment (in spite of the effect that climate change is having on farmers) they need to do something if they want to fulfill their claims of protecting the economy! Thanks to Chris Samuel for informing me of this.

Share This

Bruce Schneier writes about Correspondent Inference Theory which deals with situations when the motives of an individual or group are inferred by the results of their actions. Both his article and the MIT article on which it is based only consider the results of terrorist actions against the US and allied countries. I believe that this is a serious mistake by Bruce, the MIT people, and most people who write about terrorism. The most sensible writing about Terrorism is by Noam Chomsky. Noam considers the definition of Terrorism in both propaganda and literally. By the literal definition of terrorism the US government is responsible for more than it’s fair share of terrorist acts performed around the world. There is no reason to believe that people in the Middle-East are any less intelligent than people in the US and Europe. It seems obvious that some of the people who’s countries are destroyed by violence sponsored by the US government will believe that the US is entirely inhabited by blood-thirsty monsters. The number of US citizens who realise what their government does and approve is very low as is the number of Muslims who know what Al Quaeda does and approve of it. The US government claims that it wants democracy in the Middle-East, and Osama bin Laden claims to want the US military out of the Middle-East. If the US forces were withdrawn from Saudi Arabia then it would probably lead to a significant increase in democracy in the region (it couldn’t get any less democratic) - both sides could get what they claim to want. The discussion of the MIT paper seems to be largely based on the fact that Correspondent Inference causes the US government (and other governments) to decrease the probability of doing anything that might meet the terrorist goals. But no-one has mentioned the possibility that the same may apply to the probability of non-state organisations doing anything that might meet the goals of the US government. The wars in Iraq and Iran have significantly decreased the capabilities of the US military, they can’t recruit enough new soldiers and the current soldiers have reduced effectiveness due to long tours of duty with short breaks. The US economy is stagnating partly due to the direct effects of financing the wars, partly due to the way the airline security theatre has hurt trade and tourism, and partly because everyone has been concentrating on other things instead of fixing the economy. When two states have a war there is always the possibility of it being ended by a peace treaty or one side surrendering. With modern communications fighting can end in a matter of hours after a cease-fire has been arranged between states. But when non-state forces are involved things become much more difficult to manage. A state can make a deal with one non-state group only to discover that another non-state group (or a dissident faction within the original group) doesn’t like the treaty and continues fighting. With non-state terrorist acts connected to Al Quaeda in the US, the UK, Spain, and Indonesia (and more acts apparently planned in other countries) it’s obvious that we aren’t going to get a clean or quick solution to this problem. It seems to me that the only way the US and allied countries can escape from Correspondent Inference is to withdraw from the Middle-East entirely. If the people of Iran or Palestine want to elect a government that you don’t like then let it go (that’s what democracy is about anyway). If a dictator seizes control of Iraq then either leave him in control or provide air-support to any province that wants to rebel and establish a democratic government. Either make a stand on the principle of support for freedom and democracy or do nothing on the principle of letting people in other countries sort out their own problems. An invasion for the wrong reasons might fool people on the other side of the world but is unlikely to fool many people who live in the target country.

Share This

Since I'm a member of the set of people "somebody better suited to explaining it" mentioned in Silvia Pfeiffer's "A Long Story of Logins", I suppose it falls to me to explain what the hell we actually did to make the thing work. A quick recap, for anyone who hasn't read Silvia's article: the Vquence website is a very AJAXy, Web 2.0 style video socialisation site. Since we want the site to be available to all as much as possible, we don't lock any part of the site away behind a "login required" page unless we absolutely have to. An unpleasant side effect of this is that, when it does does come time for you to login, pushing you off to a separate "please login" page is going to be, well, a pest. There's all sorts of state about what the user is up to (it's a web-based video mashup creator, after all) that we need to submit -- but only after the user has logged in. Enter the realm of the Web 2.0 Login. Instead of sending the user to a login page, getting them to login, and then redirecting them back to where they want to go, you just have some sort of popup form that, when submitted to, does a background request and logs the user in behind the scenes. This isn't a new concept by any means -- for example, try voting up or down a link on reddit when you're not logged in. However, most sites that implement this sort of thing (based on our brief informal survey around the office) don't protect the password information in any way -- it goes over the wire as a plaintext HTTP request. We don't like this, so we wanted to send the login form over HTTPS. And there began our problems. The trivial implementation of a Web 2.0 Login page is as you'd expect -- the AJAX stalwart, XmlHttpRequest, POSTing to a handler somewhere that validates the login, sets a session, and sends back some javascript to change the page layout a bit to show you're logged in. We had this working nicely, until we started testing on our staging environment, where HTTPS comes into play... You see, XmlHttpRequest doesn't like making a request to a domain other than the one that the main page comes from -- for security. It also thinks that the same hostname via a different protocol counts as a different domain, for the purposes of this security check. (I can see the theoretical reasoning for it, but it is a bit weird for HTTP to HTTPS transitions) So if you want to POST to https://www.vquence.com/something using XmlHttpRequest, you need to be doing it from a page which is retrieved from somewhere in https://www.vquence.com/ as well. We considered just turning on HTTPS across the board, but that would have all sorts of unpleasant ramifications, so we decided against that. But the problem remained, how do we get the user's credentials to our server in a secure manner with a minimum of unpleasantness? We came up with all sorts of options. This is where the infamy of "bug #93" started -- it's a monster of a bug log. Lots of it is me going "we could do this, but it'd suck, or we could do this, but it would suck". Finally, Silvia (I think) suggested we look at using an iframe. "Eeew" was the general response, but it might at least give us a way to set a part of the page to HTTPS, which we could use as a launching point for our XmlHttpRequest call. While researching how to make this all work (I had, to my great pride, never inflicted an iframe on the world before), I managed to come across a few articles on how you can use a hidden iframe to handle requests instead of using XmlHttpRequest. Basically, the trick is that you do a regular POST on your main page, but set the target of the form to a hidden iframe in your page. A general discussion of the principle is available At the Apple Developer site, and there's also a Rails plugin that implements the concept rather nicely. When I found these, I briefly danced for joy. My quest was over. POST to the iframe, the iframe get some JS back from the server, JS mangles the main page's layout to show the user is now logged in... aaaand profit. Like fun it was. My implementation was short and sweet -- a true work of genius (if I do say so myself). Everything worked like a charm. Until we got it back into staging. Then cross-domain security bit me again. Naturally, if you don't want XmlHttpRequest calls to perform cross-domain, you probably don't want iframes for different sites to be manipulating each other's content either. That's exactly what happened -- the iframe can't manipulate the main page's layout as we need it to. Why I didn't think of this before I charged mightily ahead I don't know. My only defence is that I've never claimed to be a web development guru. Sneaky tricks will defeat any security measure, though. For instance, we control both sites (http and https), so we can send the user back to the unsecured site after login and then that location (still in the hidden iframe) can manipulate the main page layout. Redirect to the rescue! That worked really well in Firefox, even with HTTPS in staging. We were saved. At least until IE came along. Bloody Microsoft, ruining all my cunning plans. IE complains when a HTTPS site redirects (using the Location HTTP header) to a HTTP site. You apparently can't turn this off. I was shocked that Microsoft cared so much about their user's data security -- it's certainly not the first thing I think of when I think "Microsoft". My faith in the world was restored when Silvia pointed me to a workaround for the problem -- if you send the redirect in a <meta http-equiv="refresh"> tag instead of a Location header, IE is more than happy to let it pass. Because obvously a chunk of HTML that says "HTTP equivalence" is completely different to a HTTP header. Sheesh. To snatch defeat from the jaws of victory, after all this brilliant hacking, I managed to make a newbie error with the contents of the http-equiv by setting the content to "0;http://www.vquence.com/blah" instead of "0;url=http://www.vquence.com/blah" (note the url=, because I sure didn't). IE complained by looping infinitely on the source URL, while Firefox just made sense of it and did the right thing. I managed to waste most of an hour of three of us over that little stuff-up. Go me! (Sorry about that guys, by the way) Feeling very chuffed, I went home for the evening. The next morning saw a browser compatibility defect in my queue -- Safari didn't like the new setup. Instead of doing the right thing, clicking on the login button would create a new tab instead of logging in. The fix? Changing the style of the hidden iframe from "display: none" to "width: 1px; height: 1px; border: 0" did the trick. Fark. So much for "hidden" iframes. What's particularly funny is that Apple's own tutorial on hidden iframes says to avoid "display: none" because NS6 doesn't like it, but doesn't mention it's own glaring deficiency in this area. So, what are the lessons learned?

• Firstly, IE is different. I knew this already, but living in an all-Linux, not-normally-a-web-frontend-developer world, I need to be reminded every now and then.
• Safari is differently different. Being a former Konqueror user, and wrangling with that browser's retardations in an earlier existence, I should have been ready for this one.
• "Code to the standards" is a crock of shit. That's not to say that we shouldn't encourage it, but I'm fairly sure that the HTML 4.01 standard is silent on whether or not an iframe with it's display property set to none is a valid target for a form submission (I had a quick look, and nothing jumped out at me). Anyone who dismisses the difficulties of web development with a hand wave and a casual "just code to the standards" will get a double-spaced, 24pt printed and bound copy of all of the W3C standards dropped on their head from a tall building.
• No matter what security measure you think has stopped you, there's always a workaround. Can't do a XmlHttpRequest to a different domain? POST to a hidden iframe (you can post to any domain you want, too -- so much for cookie security). Want to run JS you got back from POSTing to a different domain? Just redirect back to the first domain. Can't redirect from a HTTPS to a HTTP page? Don't use a HTTP redirect, use a meta refresh. Sigh.
• Hidden iframes are cool. While I'm firmly in the "frames are evil" camp, they're a nice freaky behind-the-scenes tool if you want to do something more than what a simple XmlHttpRequest gives you. It's like having a whole separate scratch-pad of a browser you can play with, and the user never has to see it.
• Web development is frustrating. I don't do a whole heap of it (I'm more a backend code / infrastructure guy), so when I do some web UI work, I have to re-learn exactly how much of a pain it is to have to cater to the needs of a bunch of different browsers, each with their own quirks and irritations. Suddenly supporting a bunch of different Linux distros seems so much less frustrating.

One problem that I have had in configuring Heartbeat clusters is in performing a STONITH that originates outside the Heartbeat system. STONITH was designed for the Heartbeat system to know when a node is not operating correctly (this can either be determined by the node itself or by other nodes in the network) and then force a hardware reset so that the non-functional node will not interfere with another node that is designated to take over the service. However sometimes code that is called by Heartbeat will have more information about the state of the system than Heartbeat can access. For example if I have a service that accesses a filesystem on an external RAID then it’s common for the RAID to track who is accessing it. In some situations the RAID hardware has the ability to “fence” the access (so that when machine B mounts the filesystem machine A can no longer access it). In other situations the RAID may only be capable of informing the system that another machine is registered as the owner of the device. To solve this problem a machine that is to mount such a device must either prohibit the previous owner from accessing the device (which may be impossible or unreasonably difficult) or reset the previous owner. Until recently I had been doing this by writing some code to extract the STONITH configuration from the CIB and call the stonith utility. The problem with this is that there is no requirement that every node be capable of performing a STONITH on every other node, and that even if every node is are designed to be capable of rebooting every other node a partial failure condition may restrict the set of nodes that are capable of performing a STONITH on the target. Currently the recommended way of doing this is via the test program. Below is an example of the command used to reset the node node-1 with a timeout of 20000ms and the result of it being successfully completed. I have suggested that the Heartbeat developers make an official interface for doing this (rather than a test of the API) and I believe that this is being considered. In the mean time the following is the only way of doing it: # /usr/lib/heartbeat/stonithdtest/apitest 1 node-1 20000 0
optype=1, node_name=node-1, result=0, node_list=node-0

Share This

I was checking idly this morning whether there was a 64-bit version of Macromedia Flash yet (there isn’t but they claim to be working on one; yes, I do know about gnash). While searching I learned about nspluginwrapper, which was quite gratifying; I have always thought that ought to be possible, but the one time I took a stab at it I got hopelessly lost in the plugin API and had to be evacuated by helicopter. If nspluginwrapper works, it will kill two of the reasons I run a 32-bit firefox on my amd64 desktop (flash and the Acrobat plugin). I have firefox working quite nicely using schroot, but there are some inconveniences - like having to mount my sshfs filesystems once outside the chroot where I want them and once inside the chroot so that I can access them in firefox. And having to keep a ton of stuff installed in the chroot, too. Of course that leaves the one other gaping omission: there’s no official 64-bit Sun Java browser plugins yet. Blackdown had a 64-bit browser plugin, but there were a number of reports of its crashiness. And there was a lot of ambiguity in the web pages I found about whether IBM’s JRE had one or not. So I fought with IBM’s registration today (their database server must’ve been horked this morning…) and downloaded their Jave 5 JRE. Well, it doesn’t. No plugin except for IA32 and PPC32. I’m guessing from the links in the documentation that the guts of their browser plugin still come from Sun. Sun claims that JDK 1.7 will have such a plugin, but no one seems to have seen it yet. I think the only realistic way this will work out is to try building one from OpenJDK, and that’s more work than I have time for this evening. Back to the chroot for now…