Julian C. Dunn

I spent part of the weekend hacking my company-issued Samsung a920 cell phone. I guess “hacking” is a bit of a strong term – my sole objective was to get certain MIDP applications installed on it. I have a nameless-but-trustworthy-source inside Bell Mobility that confirms they block the download of MIDP apps that it doesn’t like, for example, MidpSSH or Opera Mini. Presumably, they do this by parsing the JAD file and rejecting source domains in the MIDlet-Jar-URLthat aren’t in a whitelist.

Fortunately, this thread on HowardForums gives you the lowdown on how to break into the a920 firmware to forcibly load MIDP applications on there. I had to really screw around with UniCDMA (i.e. randomly selecting different phone models) before it would spit out my SPC, but eventually I got it. The instructions on using Qualcomm’s EFS Explorer worked like a charm.

I have to admire the phone developers for their humour in naming various directories on the phone’s filesystem. The root is called "brew", presumably because the phone is Java-capable. The _policy.txt file that you can overwrite in order to remove some of the restrictions on the phone lives in a directory called "obione". (I didn’t touch the _policy.txt because I accomplished my goal just by writing the apps to the phone’s filesystem, which is good enough for me.)

Anyway, I now have Opera Mini and MidpSSH running nicely on the phone! (Nicely, I guess, if you consider that typing SSH commands using T9 is pretty painful.)

I have to start by giving the punch line first: I’m just appalled at Novell’s support story around SLES and SLED 10. In this article, I’ll explain why. Continue reading…

It was busy in June and July over at $WORK, so I didn’t get a chance to write any entries here. Some of the work I’ve been doing include turning off all legacy servers (among the legacy servers are only 2 FreeBSD boxes and a handful of HP/UX dinosaurs, but the rest of the production environment is SUSE Linux Enterprise), shepherding the BlueArc storage upgrade through (a huge pallet containing disks, controllers, disk shelves, and a replacement Fibre Channel switch arrived last week), and, of course, planning our upgrade to a modern Apache/Java environment. This will consist of Apache 2.x with a Tomcat 5.5 back end — a far cry from our current Apache 1.x and Tomcat 3.x setup.

One of the major challenges is getting Tomcat 5.5 running on SLES 9 under a Java 1.5.x virtual machine. Actually, it’s not so much the “running” part — I’m sure that since it’s Java, it would just run if I did the old tar zxvf tomcat-5.5.tar.gz && make && make install dance. But we’re after sensible package management here, and that means trying to make SLES 9 behave the standard way. SLES 9 is missing a lot of the “standard” tools that folks use to manage Java apps; it has no jpackage-utils built-in, it doesn’t use the alternatives system, and it can’t talk to Yum repositories out of the box. The work instructions I developed here hack up the base OS a bit to bolt on these tools, but ultimately do the job.

The long-term solution, of course, is to move to either SLES 10 or RedHat Enterprise Linux 5. SLES 10 ships Tomcat 5.0.x out of the box (just like SLES 9) so on the surface, it doesn’t seem like much of an improvement. But they have moved to the alternatives system; jpackage-utils is bundled with the base system, and ZMD (for what it’s worth) will talk to Yum repositories. (Of course, that’s in theory: in practice, as with many Novell tools, it’s broken.) RHEL 5 seems like the obvious answer, since it ships Tomcat 5.5 right out of the box.

Anyway, that’s a bit of a digression. Here are my directions for getting Tomcat 5.5 installed and properly package-managed on SLES 9 with JPackage. Continue reading…