H.E.C. Geek

Qt for the BlackBerry PlayBook

2011-10-24T00:49:00.000-04:00

At the keynote to the BlackBerry Developer Conference last week, two very interesting things were announced. First, the BlackBerry PlayBook Native SDK is finally in public release (it had previously been in a semi-closed beta). Second, RIM unveiled the Native Open Source Components Initiative on GitHub. This GitHub site includes ports of many open source libraries to the PlayBook, including the Qt Framework! The only real downside here is that all they've done so far is to push out the code. No how-to documentation has been provided. Therefore, I'm going to attempt to give a walkthrough for setting yourself up to use their Qt port for PlayBook development.

Before we begin, I'm going to make the following assumptions:

You are using Linux (MacOSX is probably similar, Windows probably has more differences)
You have a Git client installed
You have installed the Native SDK in: /opt/RIM/bbndk
You have already requested and installed code signing keys
You have generated a debug token, and saved it in your home directory as "debugToken.bar"
You have an actual PlayBook, on an IP address your computer can connect to, that is in development mode with the above debug token installed.

(I'm sorry if those are a lot of assumptions, but RIM's own documentation covers all of those steps and I'd rather not get sidetracked.)

Downloading and Building Qt

First, put the following line at the bottom of your .bashrc file:

source /opt/RIM/bbndk/bbndk-env.sh

(Seriously, just do it. If you don't, then I don't want to hear all sorts of complaining about how various commands can't be found during the build processes to follow. If you insist on not putting that in your .bashrc, then make sure you run it in every single new shell window you open before doing anything I'm about to discuss.)

Now, time to download and build Qt:

~/pbdev$ git clone https://github.com/blackberry/Qt.git
Cloning into Qt...
remote: Counting objects: 46226, done.
remote: Compressing objects: 100% (29220/29220), done.
remote: Total 46226 (delta 14755), reused 45939 (delta 14468)
Receiving objects: 100% (46226/46226), 158.41 MiB | 832 KiB/s, done.
Resolving deltas: 100% (14755/14755), done.
~/pbdev$ cd Qt
~/pbdev/Qt$ ./configure-qsk arm v7le
 .  .  .
Qt is now configured for building. Just run 'gmake'.
Once everything is built, you must run 'gmake install'.
Qt will be installed into /home/octo/pbdev/Qt/stage/nto/armle-v7/usr/lib/qt4

To reconfigure, run 'gmake confclean' and 'configure'.

~/pbdev/Qt$ make
 .  .  .
~/pbdev/Qt$ make install
 .  .  .

Your first Qt app

Yes, now I'm going to show you how to build/package/install a simple "hello world" application. Once you get past this point, its mostly normal Qt development.

This example application consists of the following files, which I'll describe in detail below:

File	Description
main.cpp	source code for the application
helloworld.pro	qmake project file
blackberry-tablet.xml	bar descriptor file
icon.png	80x80px icon
splashscreen.png	1024x600px splashscreen image

main.cpp

#include <QApplication>
#include <QPushButton>
#include <QWidget>

int main(int argc, char *argv[])
{
    QCoreApplication::addLibraryPath("app/native/lib");
    QApplication app(argc, argv);

    QWidget window;
    window.resize(1024, 600);

    QPushButton quit("Quit", &window);
    quit.setGeometry(422, 100, 180, 40);
    QObject::connect(&quit, SIGNAL(clicked()), &app, SLOT(quit()));

    window.show();
    return app.exec();
}

This is a pretty basic Qt sample application so far. The only unique part is the first line, where we are explicitly telling QCoreApplication to add a library path. This is necessary to enable the application to find the QPA plugin that RIM provides as part of their Qt port. What is important to note is that the path is relative to the directory the app will be executed from on the device.

helloworld.pro

QMAKE_LFLAGS += '-Wl,-rpath,\'./app/native/lib\''
LIBS += -lbbsupport

SOURCES += main.cpp

package.target = $${TARGET}.bar
package.depends = $$TARGET
package.commands = blackberry-nativepackager \
    -devMode -debugToken ~/debugToken.bar \
    -package $${TARGET}.bar -arg -platform -arg blackberry \
    blackberry-tablet.xml $$TARGET \
    -e icon.png res/icon.png \
    -e splashscreen.png res/splashscreen.png \
    -e $$[QT_INSTALL_LIBS]/libQtCore.so.4 lib/libQtCore.so.4 \
    -e $$[QT_INSTALL_LIBS]/libQtGui.so.4 lib/libQtGui.so.4 \
    -e $$[QT_INSTALL_LIBS]/libQtOpenGL.so.4 lib/libQtOpenGL.so.4 \
    -e $$[QT_INSTALL_LIBS]/libQtNetwork.so.4 lib/libQtNetwork.so.4 \
    -e $$[QT_INSTALL_LIBS]/libbbsupport.so.4 lib/libbbsupport.so.4 \
    -e $$[QT_INSTALL_PLUGINS]/platforms/libblackberry.so lib/platforms/libblackberry.so

QMAKE_EXTRA_TARGETS += package

This file does a lot of important things:

Configures the linker to hard-code the path, relative to the directory the app will be executed from, where the Qt libraries will be installed
Includes the "bbsupport" library, which allows the app to interface with the device in a Qt-friendly way
Adds a special make target ("make helloworld.bar") that builds a BAR file with the following characteristics:

Development-mode build, using a debug token
Passes command-line arguments to use the "blackberry" QPA plugin
Bundles all the resources and libraries our app may need

blackberry-tablet.xml

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<qnx xmlns="http://www.qnx.com/schemas/application/1.0">
    <id>org.demo.helloworld</id>
    <filename>helloworld</filename>
    <name>Hello PlayBook</name>
    <versionNumber>1.0.0</versionNumber>
    <description>Hello World Example Application</description>
    <copyright>2011</copyright>

    <initialWindow>
        <systemChrome>none</systemChrome>
        <transparent>false</transparent>
        <autoOrients>true</autoOrients>
        <aspectRatio>landscape</aspectRatio>
    </initialWindow>

    <publisher>Logicprobe.org</publisher>
    <permission system="true">run_native</permission>
    <category>core.games</category>
    <icon><image>res/icon.png</image></icon>
    <splashscreen>res/splashscreen.png</splashscreen>
</qnx>

The descriptor file is pretty standard for the PlayBook, and described in far greater detail within RIM's own documentation.The graphics are not provided here, but you can use any appropriately sized PNGs of your choosing. If you omit the splash screen, remember to remove it from the descriptor file as well.

Building and installing

~/pbdev/helloworld$ ../Qt/stage/nto/armle-v7/usr/lib/qt4/bin/qmake
~/pbdev/helloworld$ make
qcc  .  .  .
qcc  .  .  .
~/pbdev/helloworld$ make helloworld.bar
blackberry-nativepackager  .  .  .
Info: Package created: helloworld.bar
~/pbdev/helloworld$ blackberry-deploy -installApp -device 192.168.1.42 -password foobar helloworld.bar
Info: Sending request: Install
Info: Action: Install
Info: File size: 6646238
Info: Installing ...
Info: Processing 6646238 bytes
Info: Progress 0%...
Info: Progress 21%...
Info: Progress 97%...
actual_dname::org.demo.helloworld.testDev__helloworld32c52fe1
actual_id::testDev__helloworld32c52fe1
actual_version::1.0.0.0
result::success

And that's all there is to it! If the size of the BAR file bothers you, try experimenting around to see if you can get away with including a smaller subset of the Qt libraries or building Qt with fewer features. However, the bulk of that size is from QtCore and QtGui.

The mythical $800 hammer

2011-10-02T15:20:00.001-04:00

I'm currently at the cusp of a major job transition. For many years, my career has revolved around the world of Gov't contracts. This began with a brief but meaningful stint as a federal employee, and has continued as a long journey through the world of Gov't contracting. I've had a lot of personal reservations about this world, mainly in terms of the dynamics of the business models it supports. With all the doom and gloom currently overshadowing the federal budget, and the industry downsizing and reorganization that is likely to follow, I think its time for me to move on.

For the last few years, I've spent a lot of my personal time on a major BlackBerry software project. At many points, this personal project has provided far more interesting technical challenges and professional growth opportunities than what I was actually being paid to work on. Soon I'll be flipping it all around, and doing mobile software development as my actual day job. I'm curious to see how it will go, and especially how I'll sink or swim in the faster-paced world of non-gov't software development.

That all being said, I'd like to offer some slightly tongue-in-cheek commentary on why everything the Gov't buys is so expensive:

Where does the $800 Hammer come from?

First you need to have a DARPA program to fund research into advanced nail insertion technology (ANIT)
Then you have some Federally-Funded Research and Development Center (FFRDC) do an involved trade study that concludes that a simple hammer is preferable to the DARPA-developed ANIT prototype.
A program executive office (PEO) now hosts an industry day presentation on the US Army's Tactical Hammer Needs to the tool-making industries
The PEO now publishes a Request For Information (RFI) to solicit information from industry on steel hardening and handle-forming capabilities that could be used for the hammers
Finally a Request for Proposal (RFP) is published, along with a detailed performance spec, requirements list, and statement of work

There are a limited number of hammers desired, with options for buying more later
They also have to conform to various Military standards that no tool you'd buy at Home Depot would ever have to conform to
They need to be made in the US in a facility that holds the proper security clearances

The PEO finally selects one of the submitted proposals, awarding the contract

One of the loosing contractors decides to file a formal protest, and drags the process out longer
Eventually a settlement is made, and the selected prime contractor takes them on as a subcontractor for handle-to-head integration tasks

After several rounds of requirements engineering, systems engineering, and product R&D, along with approvals at preliminary and critical design reviews (PDR/CDR), the government gives the go-ahead to enter Low-Rate Initial Production (LRIP)
Testing eventually finds issues in the initial batch. Some design changes are made, costs are passed along, and eventually the hammer enters full-rate production (FRP)
Following training and deployment, the MK42 Tactical Nail Insertion Device (code-name "Hammer") is deployed into the field
Meanwhile, nails are getting tougher, and follow-on program for the MK49 Objective Nail Banger is announced

C# WTF: Abuse of events

2008-03-07T11:14:00.000-05:00

Someone actually noticed my last post, so I'm going to start putting more of that stuff on here.

Getting a property through events:

Common uses:

Pretending to decouple classes for no apparent reason.

public delegate int GetSomeValueDelegate();
 
class Foo
{
    public event GetSomeValueDelegate GetSomeValue;
 
    public void DoStuff()
    {
        /* . . . */
        if (this.GetSomeValue != null && this.GetSomeValue > 4)
        {
            OtherStuff();
        }
        /* . . . */
    }
}
 
class Bar
{
    private Foo foo;
    private int someValue;
 
    public Bar()
    {
        foo = new Foo();
        foo.GetSomeValue += new GetSomeValueDelegate(this.HandleGetSomeValue);
    }
 
    public void Run()
    {
        foo.DoStuff();
    }
 
    private int HandleGetSomeValue()
    {
        return this.someValue;
    }
}

Common variants:

Having the event return a reference to the Bar instance that manages Foo.

Having the event return a property of singleton that is accessible from both classes.

Externalizing logic through events
Common uses:

Decoupling a class from its internal logic.

public delegate void ResultsEventHandler(string[] results);
 
class Foo
{
    public event ResultsEventHandler ResultsEvent;
 
    private string[] resultsData;
 
    public string[] Results
    {
        get { return this.resultsData; }
        set { this.resultsData = value; }
    }
 
    public void DoStuff()
    {
        string[] results = PerformOperation();
        if (ResultsEvent != null)
        {
            ResultsEvent(results);
        }
    }
}
 
class FooManager
{
    private Foo foo;
    private Bar bar;
 
    public FooManager()
    {
        foo = new Foo();
        bar = new Bar();
        foo.ResultsEvent += new ResultsEventHandler(this.OnResultsEvent);
    }
 
    public void DoStuff()
    {
        foo.DoStuff();
        ProcessResults(foo.Results);
    }
 
    private void OnResultsEvent(string[] results)
    {
        foo.Results = results;
        bar.Data = results;
    }
}

C# WTF: Abuse of exception handlers

2008-01-03T10:31:00.000-05:00

I've started collecting assorted examples of bad code, and will start periodically posting them. Everything seen here was first seen in real code (and fixed, when possible). Just remember, these are examples of what you shouldn't ever do! :-)

Type checking by InvalidCastException:

Common uses:

Checking the type of an object in a collection when the developer does not know about the "is" operator or its equivalents.

Selection selItems = UtilServices.GetInstance().GetSelectedItems();
if (selItems != null)
{
    try
    {
        foreach (object item in selItems)
        {
            // Cast to a Foo Item.
            FooItem fooItem = (FooItem)item;
        }
        ProcessSuccess();
    }
    catch (System.Exception ex)
    {
        // If an exception is thrown, the items are not FooItems
        Logger.Error("Exception: " + ex.Message);
        ProcessFailure();
    }
}

Null checking by Exception handler:

Common uses:

Not being bothered by the hassle of all those "if" statements.

try
{
    foo = bar.GetSomeData();
    thing = foo.ThingValue;
}
catch
{
    foo = bar.GetOtherData();
    thing = foo.ThingValue;
}

Converting from a DIB to a System.Drawing.Bitmap

2007-04-12T08:07:00.000-04:00

Yes, I even do some .NET programming in C# these days. Don't worry, its just at my day job. In any case, since everyone and their brother, cousin, and best friend seems to have a blog with random .NET tidbits, I figured I'd add one here too. (Speaking of which... Please, people, your blogs aren't so important that you need to fill 75% of it with links to other people's blog postings, lest your "special" readers never know about them. It makes Googling painful at times.)

In any case, I found myself inside some code that got an image (in native Windows "DIB" format, as an object that was of type "byte[]") and needed to convert it into a System.Drawing.Bitmap. The code actually did this already, by extracting the image size from the DIB header, creating a new Bitmap, then proceeding to iterate over every single pixel to directly set it in the Bitmap. Obviously that was way too slow, and a better solution was needed.

I then searched the web far and wide, not really finding anything useful. Sure, there were a lot of hints, but no real solutions. Bitmap itself actually has no easy way to be created from a byte array. What it does have, strangely enough, is the ability to be created from a pointer to unmanaged memory and some hints:

public Bitmap (
int width,
int height,
int stride,
PixelFormat format,
IntPtr scan0
)

Since I had my data in a byte[], not as a chunk referenced by an IntPtr, the first step was to remedy the situation. Here is how you do it, as weird as it may look:

GCHandle handle = GCHandle.Alloc(dib, GCHandleType.Pinned);
IntPtr handlePtr = handle.AddrOfPinnedObject();

(When you are done using the handle, don't forget to call "handle.Free()".)

Now all I had to do was offset the IntPtr by 40 (size of the DIB header), add in the information the existing code already extracted from the header, and create a new bitmap. Here's the final result:

using System.Drawing;
using System.Drawing.Imaging;
using System.Runtime.InteropServices;
...
GCHandle handle = GCHandle.Alloc(dib, GCHandleType.Pinned);
IntPtr handlePtr = handle.AddrOfPinnedObject();
IntPtr scan0 = new IntPtr(handlePtr.ToInt32() + 40);
Bitmap bitmap =
new Bitmap(width, height, width * 3, PixelFormat.Format24bppRgb, scan0);
handle.Free();
...

It may look ugly, and very icky, but it does work. In fact, this allowed me to take an operation that took two whole seconds of wall-clock time and make it instantaneous.

Frameworks, oh my!

2006-11-06T18:57:00.000-05:00

Earlier this evening, I was having a little chat with my good friend and development wizard Chris. I was chatting with him about a recent frustration with the world of certain "Frameworks".

As I proceed forward in a software engineering class project involving an application built on JavaServer Faces running on top of GlassFish, I found myself reminded on this rant someone sent me a link to recently. While I ultimately have a far more balanced view, I do find his rambling somewhat amusing.

So anyways, here's my rant:

After a group meeting for my class, it looks like the most sensible way to design our web pages for this web app is essentially a templated composite view, so we can have standard headers, sidebars, etc, without having to code them on each page.

As such, I start looking up how to do them properly in the context of JSF (JavaServer Faces), which conventionally uses JSP (JavaServer Pages) for its page description system.

Then I start reading that you can do it this way, or that way, but that those ways all have problems for this reason or that reason.

In fact, most conventional documents on how to use JSF ignore the problem completely.

But when they discount all the obvious ways, they then recommend this alternate page composition system called "Facelets".

So I start reading up on Facelets, and it says how they use XHTML instead of JSP, because JSP is bad for this reason or that reason, especially with JSF, and talk all about how Facelets and JSF go wonderfully together.

As such, I look into what it'll take to have Facelets integrate cleanly with my chosen IDE (NetBeans), which I chose because it integrates so well with the other ways I was trying to do things.

I discover a NetBeans plugin that'll let me to Facelets, and provide all that tag-completion on the XHTML files that I was getting in the JSP files. Only problem is that its at version 0.3.

I install it anyways, and finally figure it all out.

In the end, Facelets has turned out to actually be a very nice solution, and I'm really happy with it.

(and since JSF supports plugable page composition systems, it integrates cleanly and correctly too)

But, given that JSF seemed to start from the basis of "we see all these other frameworks out there designed to fix/improve-upon what JSP provides", I wonder why I didn't start with reading about Facelets.

(and in general, I'm actually quite pleased with the whole JSF approach)

I just wish Facelets got more coverage in my JSF-bible-type book (published last month, co-authored by one of the spec leads). All it got was a few examples in the short chapter on plugable page rendering libraries.

The Java Preferences API vs. MacOS 10.4

2006-10-30T10:21:00.000-05:00

While it may not be obvious from all my sysadmin-style tinkering discussed in this blog, I am also a software developer. Lately I've been working on a Java GUI program that has to save and load a complex tree of settings. While the project is nearing its completion, I've decided to occasionally spend some time trying to find and fix various issues and performance bottlenecks. This is the story of one of those bottlenecks...

A common way to save and load application preferences in Java, is to use the Preferences API. This API uses a different back-end implementation on each operating system, but essentially provides a tree view for storing preferences. Its implementation is also intended to make the backing-store somewhat transparent, so you just have to set your preferences. There is no need to perform a "save" operation afterwards.

Now first of all, I did want to make saving an explicit operation in my application. So while I maintained my own configuration tree, writing it to nodes in the Java Preferences tree was a user-triggered operation. Originally I also wrote out the Preferences tree to a file on disk, which was loaded in place of Java's Preferences store. However, upon realizing that was a needless waste of resources, I removed the external configuration file.

One major part of my application involves configuring a number of "thingies," where each "thingie" has a potentially large number of individual parameters directly under its configuration node. A problem I noticed was that as I increased the number of "thingies" in the configuration, save and load became dramatically slower. However, here's the really interesting part. It only really became slower on MacOSX! On my Linux test machine, the performance impact wasn't even noticeable!

Thanks to the wonderful profiler in NetBeans, I was able to track down this issue to functions under "java.util.prefs.AbstractPreferences", or more particularly "java.util.prefs.MacOSXPreferences". Apparently the MacOSX implementation of the node() and various put() methods can be quite slow. If you have enough of them, it really adds up.

So how did I fix it? Well, something a bit less elegant than how I was doing things before. You see, the save and load methods for "thingie" configurations really just involved converting items between a Map and Preferences nodes. Since the Map really just managed access to an object which contained a collection of simple types (String, Integer, etc.), I got an idea. Why not just serialize the Map directly, and store it as a byte array in a Preferences node? Sure, it may seem like a bit of an inelegant solution, but it worked! Not only did it work, but it resulted in a MASSIVE performance increase.

So how much of a performance improvement does this make? Reading the program's configuration used to take 2195ms, according to the profiler. It now only takes 956ms. However, writing used to take 7314ms. Now that number is down to 645ms!

So, what did we learn?
1. Java performance characteristics can vary wildly across operating systems.
2. Object serialization to a byte array node in the Java Preferences system can be significantly faster than creating an elegant structure within the Java Preferences API to store a lengthy configuration, especially on MacOSX.

Yet Another IPv6 Setup

2006-09-01T19:30:00.000-04:00

Last weekend I got the bright idea to give IPv6 another attempt on my network. I had previously tried it a while back, tunneling straight from my Cisco router. However, I had an older Cisco router that could only do IPv6 on a "testing" build of IOS. Being sick and tired of potential "issues" with this build, I wound up just ditching IPv6 for the time being. At the time I had a single static IP, and I did not have any other good configuration options.

These days I have a connection with multiple static IPs, so I have more options available to myself now. My current network config is also rather interesting, so allow me to illustrate:
{Internet} ---->(Cisco 4500 rtr)---->(FreeBSD firewall)====>{Multiple internal subnets}

Basically I've banished all NAT to that Cisco, which does the common port-translating NAT for most machines on my network. However, it also does 1:1 (bi-directional) NAT for my firewall and server machines. The advantage of 1:1 NAT is that you only translate the network address, and nothing else. As such, you can use it for a lot more than just the usual restrictive TCP and UDP setup you have with port-translating NAT. Of course 1:1 NAT does just translate network addresses, so you need to configure your firewall as if your machines did have public addresses.

So coming out of the Cisco router, I have my private address range (with some public IPs mapped to some of the private IPs). Just behind it, the FreeBSD firewall takes the next step. First, it filters out any traffic I don't want going into my network (obviously). Second, it takes this private address range and subnets it further. (the internal side of the box is a VLAN trunk to my switches) Yes, I have multiple subnets internally. This lets me separate different types of traffic for the purposes of flexibility and/or security.

Basically, I wanted to connect my various internal networks to the IPv6 Internet, by way of this FreeBSD firewall. (FYI, the system is running FreeBSD 6.0-RELEASE at the time of this writing, and is named "Tritanium") To accomplish this, I had two main options at my disposal:

Use a "tunnel broker" service (i.e. Hurricane Electric, Hexago, or Sixxs)
Use a 6to4 tunnel (RFC3056)

The last time around, I used a tunnel broker. However, this method depends on having an active account with an external service. While that does work, it is a bit of an annoyance it would be nice to do without.
As such, I decided to attempt 6to4 this time around. The 6to4 method works by directly mapping your public IPv4 address into an IPv6 /48 subnet. Then your border router essentially tunnels IPv6 packets directly inside IPv4 packets (as IP protocol 41). What's really cool about this is that you don't need any external services or configurations. If you go to an IPv6 site, and ping your local 6to4 address, you will see the inbound packets while sniffing your external interface. So, with all that being set, time to get on to an account of my experiences:

Step 1: Figure out your IPv6 address
This is probably the easiest step of the entire adventure. You just take your public IPv4 address (yes, it does have to be a public routable address), convert it to hexadecimal, and tack it onto the end of the 6to4 prefix (2002). For the sake of this writeup, lets assume our public address is "12.34.56.78". In hex, that translates to "0C22384E". So that translates into the following 6to4 subnet:
2002:c22:384e::/48

(IPv6 lets you omit leading zeros and abbreviate the end of the address, in case you were wondering.)

Step 2: Configure the 6to4 tunnel
This was probably one of the most frustrating steps, despite the fact that it looks like it should be the easiest. I blame my configuration more than anything else, though. You see, while the external interface on Tritanium maps directly to a public IP address, it actually has a private IP address itself.

In short, you have to configure FreeBSD's stf(4) interface with your 6to4 address, and then setup routing. However, I had a bit of a problem. You see, for this to work in both directions, two things had to happen. First, Tritanium had to have something telling it that it did indeed have a relationship with its public IP. Second, certain sanity checks (that prevent you from using stf with private IPs) had to be bypassed.

The first step was easy. I just created an alias on Tritanium's external interface with its public IP address, and a /32 netmask:
# ifconfig fxp1 inet 12.34.56.78 netmask 0xffffffff alias

The second step turned out to be a lot more involved. What's going to happen is that Tritanium will be receiving incoming 6to4 packets where the IPv4 address (1:1 translated to a private IP by the Cisco router) will not match the IPv6 address (based on our public IP) contained within. Let's just say that it does not work out of the box. Upon reading the stf man page, it does however tell us that the: "Ingress filter can be turned off by IFF_LINK2 bit". (this is the "link2" flag you can pass to ifconfig when setting up an interface)

Glossing over what was an entire night of frustration and debugging, let's just say that LINK2 doesn't really do much of anything. The stf interface driver has a lot of sanity checks, some failing with my configuration, and the "ingress filter" block of code that LINK2 disables isn't one of those checks.

The fix I ultimately came up with involved fixing the source code (if_stf.c) to make the LINK2 flag disable the sanity checks that were failing on my setup. The result of my fix can be summed up in this patch. (yes, it is against 6.0-RELEASE, but it shouldn't be hard to adapt to a newer version)

Once that file was patched, and the kernel module reloaded, the next step was pretty simple:
# ifconfig stf0 create
# ifconfig stf0 inet6 2002:c22:384e::1 prefixlen 16 link2

The third step involves setting up routing. For this, we need to create a route to a public 6to4 router. I took the easy way with this one, as there is a public "anycast" address for your nearest 6to4 router. That address is 192.88.99.1 (in IPv4), or 2002:c058:6301:: (in 6to4 IPv6). So I set my default IPv6 route to that:
# route add -inet6 default 2002:c058:6301::

Step 3: Internal subnets and routing
First I set IPv6 addresses on my internal interfaces, using subnets of the /48 that I got with 6to4:
# ifconfig vlan1 inet6 2002:c22:384e:1::1 prefixlen 64
# ifconfig vlan2 inet6 2002:c22:384e:2::1 prefixlen 64
# ifconfig vlan3 inet6 2002:c22:384e:3::1 prefixlen 64
# ifconfig vlan4 inet6 2002:c22:384e:4::1 prefixlen 64

Then I enabled IPv6 forwarding:
sysctl net.inet6.ip6.forwarding=1

Finally, I enabled rtadvd(8) in my rc.conf, and also told it which interfaces to run on (a subset of the ones above), and then started it:
# /etc/rc.d/rtadvd start

In case you were wondering, "rtadvd" is the router advertisement daemon. Using it, all my internal IPv6-enabled systems will automatically learn their IPv6 network addresses and routers. Pretty cool, eh?

Step 4: The firewall
While the IPv6 Internet is probably not yet anywhere near as hazardous as the IPv4 internet, chances are that you still want some level of protection. Since I used to use OpenBSD for my firewalls in the past, I had become accustomed to using pf(4). Unfortunately, I discovered that pf has a very annoying problem with my configuration. Just having pf enabled (even with all rules flushed) seemed to inhibit IPv6 packet forwarding! It was actually kinda strange how it behaved. I could talk normally on the IPv6 Internet from Tritanium directly. However, only ICMP worked correctly from my internal machines. Outbound TCP and UDP packets were never forwarded across Tritanium, while inbound ones worked just fine.

What's the solution? Use ipfw(8) instead of pf, and your problem will be solved. Just make sure you configure the IPv4 side of ipfw so that IP protocol 41 packets are permitted unscathed. (my version wouldn't let me specifically allow proto 41, for some strange reason, so I just permitted all IP packets that I hadn't explicitly blocked with some other rules elsewhere in my configuration.)

Step 5: And there was much rejoicing!
I'm now connected to the IPv6 internet, after a week's worth of evening tinkering. Yippee!
I may eventually put all my configurations into rc.conf (I had some difficulties when I first tried, and gave up soon afterwards), but right now most of this stuff is just running out of rc.local on the machine.

Solaris Live Upgrade (on an SVM mirror set)

2006-08-14T22:15:00.000-04:00

Many of you have probably heard of Sun's live upgrade feature by now. Live upgrade essentially lets you upgrade your system from one Solaris version to another with minimal downtime. If done right, the only downtime you need to suffer is the time required for rebooting your server.

Live Upgrade works like this:

Create a "boot environment" (BE) representing your current system
Create an "alternate boot environment" (ABE) which is a clone of your BE
Run a Solaris upgrate against the ABE
Switch the active "boot environment" to the ABE
Reboot

Seems simple enough, right? Well, on the surface it does seem simple. There's just one problem. You need an empty partition to use as the ABE! You know what really annoyed me though? Most of the LU examples and docs I've read seem to involve using some random extra scrap of a partition for the ABE. Well, as you can probably guess, the ABE becomes your system boot partition at the end of this process. Do you really want some random scrap partition to be your system partition for the long term? I certainly didn't.

This whole procedure is also easier if you separate your system partitions from your data ones. Yes, I know this is normally a good practice. However, I've grown to just use a huge "/" and smaller "/var" on most of my machines these days. It's just easier, and I still have "/home" on an external file server.

So what was I to do? The Solaris 10 6/06 DVD set was here, and I wanted to upgrade. (my server was running the original Solaris 10 release) I needed something large to make my ABE on, but also needed it to be somewhere I was comfortable using as my long-term boot drive. I also wanted to avoid involving anything beyond that server itself. Then it occured to me... the "system disk" of my server was actually an SVM mirror set!

In short form, here was my plan of action:

Make a backup (thankfully this machine has a DDS3 drive installed in it)
Remove the second disk from the mirror and unconfigure its meta devices
Run live upgrade, using that second disk as the ABE
Switch the default BE to the one on the second disk
Boot off the second disk, into the new version of Solaris
Make sure the server is still working correctly
Unconfigure the mirror devices in SVM
Recreate the meta devices on the second disk, mirrors containing them, run metaroot, etc.
Reboot again
Add the first drive back into the mirrors

Seems simple enough, right? ;-) When all is said and done, the goal was to have the same drive configuration before. The only differences would be that my mirror components would be reversed, and I'd be running a newer version of Solaris.

While I should now show a complete walkthrough of what I did, a full post-mortem reconstruction would be rather tedious. Besides, if you're familar with SVM and can read through Sun's LU docs, following my strategy should be straightforward and simple. (yes, it does work) Just remember to install the recommended patches before using LU, or it'll fail.

Also, I strongly recommend mounting the upgraded ABE before that first reboot. You should then check the "/var/sadm/system/data/upgrade_cleanup" file for any changes of interest that it made. I failed to do this myself, and wound up having sendmail misconfigured for several hours. On the bright side, it does make backup copies of any configuration files that it changes.

Good luck!

Fun with Solaris 10 6/06 and ZFS

2006-08-14T21:41:00.000-04:00

The 6/06 release of Solaris 10 finally incorporated ZFS as part of the operating system. This is quite exciting, because now we can start using ZFS without having to run a Solaris Express or OpenSolaris distribution. As such, I was itching to try it out. I started by ordering the "Solaris Enterprise System" DVD stack from Sun. Sure, I could have downloaded it, but its nicer to have a whole set of media already there for me.

Now I needed a test system... So I dug out my older Ultra 60 workstation, hooked up a DVD drive, and a few hours later I was good to go. Thus far, the only real change I noticed from the original Solaris 10 release was a newer and nicer looking login screen.

Time to hook up a boatload of hard drives! I had an expansion box from my now-since-decomissioned CLARiiON FC RAID monster, good to go with 10x36GB 10krpm FC hard drives. All I needed to do was connect them, reformat them with a normal block size (they were formated for 520 bytes instead of the normal 512, thanks to the CLARiiON controller), and I'd be good to go. Unfortunately, all I had to connect them to was a QLogic QLA2100 FC HBA. The QLA2100 isn't supported past Solaris 8, or so they'd lead you to believe. Thankfully you just have to get the Solaris driver, unpack it from the package stream QLogic provides, modify the package to not complain about your Solaris version, and install it. As expected, it then worked just fine.

To fix the block size on the drives, I got the "scu" utility from here, and then followed the instructions on this page. All pretty straightforward, but it did take about an hour per drive. It doesn't really do much I/O to to the drive from your system, though, so doing all the drives at once does speed things up.

Finally, I went through "format" on each drive to fix the annoying "bad magic" messages. Now I had 10 drives off the end of an FC link, all set and good to go!

Setting up ZFS was really easy. If you haven't done so yet, I strongly recommend going here to review their documentation and screencasts. The specific commands are really easy to figure out, but that site shows them to you. Essentially, with ZFS, you make a pool out of mirrors, RAID-Z sets, or individual disks. You can then chop up the pool however you see fit.

In any case, I tried a few configurations and ran some benchmarks. Keep in mind that testing with "dd" and a large block size will ALWAYS yield better results than you'll ever see on a real benchmark program. (I think I got up to 80MB/s with "dd" at some point) Also, running multiple benchmark programs or "dd" sessions in parallel may also yield higher throughput. FYI, I was connecting to all 10 drives over a single 100MB/s FC link. So on with the results!

One 10-drive RAID-Z set


$ bonnie++ -d . -s 2G
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                  -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
proxima          2G 14685  91 35308  48 23733  49 13301  92 52396  50 512.1  13
                  ------Sequential Create------ --------Random Create--------
                  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
            files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               16  4798  99 +++++ +++  7455  99  5230  99 +++++ +++  7350  97
proxima,2G,14685,91,35308,48,23733,49,13301,92,52396,50,512.1,13,16,4798,99,+++++,+++,7455,99,5230,99,+++++,+++,7350,97

One 5-drive RAID-Z set


$ bonnie++ -d . -s 2G
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
proxima          2G 15241  94 32991  44 24989  45 13676  93 58862  52 550.2  10
                   ------Sequential Create------ --------Random Create--------
                   -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
             files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                16  4821  97 +++++ +++  7509  99  5190  98 +++++ +++  7849  99
proxima,2G,15241,94,32991,44,24989,45,13676,93,58862,52,550.2,10,16,4821,97,+++++,+++,7509,99,5190,98,+++++,+++,7849,99

Two 5-drive RAID-Z sets


$ bonnie++ -d . -s 2G
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
proxima          2G 15051  92 30531  41 26045  47 14018  93 57507  56 864.6  12
                   ------Sequential Create------ --------Random Create--------
                   -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
             files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                16  4908  99 +++++ +++  6800  95  4868  99 +++++ +++  5847  81
proxima,2G,15051,92,30531,41,26045,47,14018,93,57507,56,864.6,12,16,4908,99,+++++,+++,6800,95,4868,99,+++++,+++,5847,81

Air Travel and Mobile Computing

2006-02-10T09:21:00.000-05:00

Almost since their inception, laptop computers have been an increasingly popular implement of the air traveler. You see them used both in airports and on airplanes, by more and more people. However, airports and airplanes today do not provide a friendlier environment for laptop users than they did years ago.

Problem #1: Electrical power
Regardless of what the makers of DC-DC converter bricks may tell you, most airplanes are not equipped with DC power outlets for passengers. Occasionally you might find them in first class, and I once saw them in coach on a short Orlando-Atlanta flight, but normally they are simply not available. As such, the only solution is having laptops with good battery life, and topping them off at airports in-between flights.

Airports, however, aren't that great either. Outlets in sitting areas tend to be very scarce, and often squatted by other laptop users or people who don't even realize they're in the way. I frequently find myself scouring the entire food court, or the entire gate waiting area, only seeing one or two outlets. Even then, I'm lucky to get access to them.

Problem #2: Internet access
Access while on airplanes is something we presently don't expect, and thus can live without. After all, for most domestic trips, the airlines don't want to keep you on the same one for more than 2 hours anyways. Sure, there is talk about installing access, but you all know how that's going to be done. It'll be prohibitively expensive, and/or only offered to first class, and will wind up being practically unavailable to your average laptop-toting passenger. (Remember the sky phones?)

Airports, however, have been installing Wi-Fi access points all over the place. Except, they do it in a way that makes it nearly useless. First, they all insist on charging for access. This is a problem because even though it is usually cheap, it is still hard to justify $5.95-9.95 for a 10 minute E-Mail check between flights. (thankfully I can use GPRS on my cell phone instead) If you are a frequent traveller, they do have monthly access plans. Of course every airport's Wi-Fi installation is managed by a different organization, and thus these plans are worthless unless you fly the "exact same trip" with long layovers on a regular basis. In essense, airport internet access is implemented in such a way that it is practically useless to most travelers on a 1-hour layover. (Well, at least until there are popular programs that can tunnel IP over DNS and ICMP, which are the only things their proxies seem to let out onto the global internet.)

New blog!

2006-02-06T08:42:00.000-05:00

My blog on LiveJournal was more like a collage of personal ramblings and reflections, and the blogs there from various friends of mine were also like that. As such, I've decided to separate out the technical content. Below you'll see a bunch of technical posts that I've copied over here. In the future, I hope to put all my technical postings on this site instead.

Why am I doing this? Well, the reasons are two-fold. First, most technical postings on LJ would get lost in the noise of personal-life ramblings from everyone on everyone else's friends pages. Second, I'd rather post these in a forum open to people that really have no need nor desire to know about any of my own personal-life ramblings.

I'd also like to have a personal tech blog to complement my efforts on this website:
Household Enterprise Computing

As well as my tinkerings with this excessive collection of operational computer hardware:
Logicprobe Systems List
(or any of the many less-operational boxes that I didn't bother to list there)

If anyone still wants to know exactly what I consider "Household Enterprise Computing" to be, here is a good writeup that I did a while ago.

The Objective Rack - Mark IV

2005-12-18T22:55:00.000-05:00

Behold, the The Objective Rack - Mark IV!

This whole rack-rebuild project took most of Saturday. Thankfully everything of mine came up ok afterwards. Unfortunately a friend's server (that I've started hosting as of last weekend) didn't come up so easily. After a whole night of frantic tinkering attempts, I backed up all the data I could salvage and we reinstalled it this morning.

This is but the latest in a continual cycle I go through....
1) Build rack all nice and neat
2) Use new setup for a while
3) Gradually decide to change things over time (add new machines, remove old machines, etc.)
4) Decide that the once-elegant rack has become a mess of tangled wires and ad-hoc mounting
5) Tear it down and repeat from step 1.

As I said, this is the 4th iteration of my attempts at building a rack of computer equipment for my personal use. Here's the history in chronological order:

Mark I - Moved to an apartment in Florida, bought the rack in the process, got everything all setup. Many of my systems weren't rackmount, so I used a lot of rack-mount shelves.
Mark II - Upgraded a lot of equipment, had a lot of new stuff to mount (including an E4000 and a big RAID box), and took the desktops out of the rack. First use of the term "objective rack".
Mark III - Moved from the apartment to a house, finally had the proper mounting kit for the E4000, needed to get everything setup again.
Mark IV - Retired some of the more power-hungry equipment (E4000 and big RAID box), changed a lot of systems around, had some new equipment and cable-guide stuff to integrate.

Prior to the rack, I went through a series of wire-shelf-based setups. These began my sophomore year of college with this setup, and continued with a new iteration every academic year.

Fun with LDAP and Kerberos

2005-12-06T23:16:00.000-05:00

Several weeks ago I decided that I want my firewall to no longer be a Solaris machine, and that I wanted a dedicated authentication/utility server. The goal was to decouple my internal utility services (authentication, DNS, NTP, etc.) from my main servers. So I dug up a cheap 1U server, put FreeBSD on it, made it my firewall/internal-router/external-DNS/et

c. box, and took my Netra T1 out of production.

Since the Netra T1 was to be the new auth server, I began last week by blowing away its prior installation and giving it a fresh load of Solaris 10. (note: always remember to make the small dedicated partition for the SVM metadb replicas *before* installing Solaris) I then got my internal DNS migrated to it, as well as NTP.

For a while, I was running good 'ole NIS to do my distributed user accounts. Of course its an old protocol, and everyone says to upgrade, but it "just f**ing works", and I can configure it in my sleep on just about any *nix. Of course the whole point of this auth server was to try something new. Originally I knew I wanted to take a shot at LDAP again, as I've tried (and failed) before, going back to NIS. As I approached this past weekend, and did some reading, I decided to take a bigger chunk and try LDAP with Kerberos.

So on Saturday I brought the Netra out to the LEAP Installfest, and started getting OpenLDAP and the Kerberos that comes with Solaris (SEAM) all installed and configured. By Sunday afternoon, I was still tinkering, and things still weren't yet working right. I figured out how to migrate my NIS accounts into LDAP, knew how to make users in Kerberos, but client authentication just wasn't working right. (it sort-of worked to my FreeBSD server, and didn't work with my Solaris one) I spend way too much time staring at PAM debuging output, and continued to be baffled.

So I said f*ck it, pulled out OpenLDAP, and went and installed "Sun Java System Directory Server 5.2". (which used to be called SunONE *something*, which used to be called iPlanet *something*, which used to be Netscape *something*) The name sounds fancy, but it really is just an LDAP server with some graphical (and the usual command-line) admin tools.

After tinkering all night, it was almost working. In the morning I figured out the magic extra LDAP user parameter to finally get authentication working. So by sometime Monday morning, I could do name lookups and authentication against the SJSDS LDAP server from both my Solaris and FreeBSD servers. However, while I had SSL configured on the LDAP server, it wasn't reaching down to the clients.

I spent all of last night attacking the SSL issue... You see, LDAP isn't really a good authentication protocol (which is different from an authorization/lookup protocol, which it is decent at). Without SSL, you have 2 authentication types... simple (your client sends your password IN CLEAR TEXT over the wire to the LDAP server), and CRAM-MD5/DIGEST-MD5 (the password isn't in the clear on the wire, but it is IN CLEAR TEXT in the LDAP database itself. (thus breaking my desire for password-hash compatability with the data I imported from NIS) In any case, but the end of the night, I got simple authentication with SSL working. Thus, no cleartext passwords anywhere.

Then tonight I got brave again... You see, the Sun JSDS docs do have a good writeup on integrating Kerberos. But when I initially tried it, the ns-slapd process (the LDAP server itself) kept core-dumping. Apparently, this was a known issue according to the release notes, and there was even a fix (which worked!). So as of the middle of this evening, I actually succeeded in getting LDAP+Kerberos fully functional across all my remote-access systems. I even figured out how to convince PAM on my Solaris server to use SSL LDAP authentication for users that don't yet have a Kerberos principal. (couldn't figure out how to tweak PAM to do that seemlessly on FreeBSD, though.) Now that Kerberos is working, its only a matter of time before I find myself fully taking advantage of what it has to offer.

In any case, I think I've conquered LDAP+Kerberos. Next step is to eventually get around to figuring out exactly what I did, and producing a detailed technical writeup to help others in the future. (sure, the web is full of such writeups, but they're all partial and I needed to piece together hints from all of them to get things working.)

Reflections on uber-geekness...

2005-10-31T16:05:00.000-05:00

As extreme and weird as we may seem in our computer-related projects, the truth is that we're often doing the same things as normal users. Its just that we find much more sophisticated ways of accomplishing them...

Normal people use laptops to get computing anywhere in the house.
Ubergeeks deploy a server infrastructure with a hot-desktable thin-client solution.

Normal people check e-mail through their ISP or something like gmail/hotmail/etc.
Ubergeeks run their own e-mail server with IMAP+SSL, SMTP AUTH, and server-side mail filtering.

Normal people use their desktop PC when they need to run a Windows application.
Ubergeeks install Windows 2000 Server on a SunPCi card in their Sun enterprise server and install Citrix Metaframe Presentation Server to provide multi-user Windows application access authenticated through Samba, and still refuse to play Snood.

Normal people listen to MP3s with WinAmp or iTunes off their desktop's hard drive.
Ubergeeks mount an NFS export from their RAID file server and play the MP3s in XMMS.

Normal people watch movies off their DVD player or their cable services.
Ubergeeks construct network-booted machines running MythTV to stream movies off their RAID file server.

Normal people buy telephones at Walmart and use them to talk to their friends.
Ubergeeks run Cat5e across their houses, and deploy an IP Telephony solution through an Asterisk box.

Normal people think a "router" is an $80 Linksys box you buy at CompUSA that lets them connect multiple PCs to the internet.
Ubergeeks think a "router" is a multi-service rackmount Cisco device with ethernet, T1, and frame-relay interfaces, capable of supporting OSPF and BGP.

A necessary evil...

2005-10-28T09:13:00.000-04:00

Yup, I'm talking about Windows here. As much as I normally avoid it, the need to use it does occasionally crop up. It could be when the g/f wants to go to some ActiveX game-tracking ESPN site, someone actually *needs* to use MS Office (the real thing), or when I want to run some embedded development software written for low-end Windows tinkerers.

Of course your usual Windows desktop is useless for this, give how my computing setup is presently designed. Outside of my personal desktop in my computer room, all my "around the house" computers basically consist of SunRay thin clients. (which provide an X-based desktop running Gnome served off a Solaris machine) Even with VNC (which is slow and crappy) or "Remote Desktop" from a normal Windows machine running your average desktop version of Windows, I'd still run into problems once more than one person wanted to use the thing at a time.

So, what I need is a mult-user remote-desktop-capable Windows machine...

For the hardware, I've got a SunPCi II card currently sitting in my Sun Blade 1000 workstation. This is a machine I plan to turn into a server soon to replace the Sun E420R which I've been using as an interim server since I decided that my Sun E4000 used too much power. In any case, I've been using the SB1000 for tinker purposes lately, so it was perfect to test out some things on. Now the SunPCi II was basically a 600MHz Celeron with 192MB of RAM on a PCI card inside the Sun. I've since upgraded it to a 743MHz Pentium III (1GHz P3 with a 100MHz FSB... darn clock multiplier locks). I also need to add RAM.

For the software, I basically had two choices... Windows 2000 Server or Windows 2003 Server. Since the SunPCi II software only supports Win2k Server, my decision was made there. So I got that installed and running. Unfortunately, to my dismay, the "Terminal Services" in Win2k server (remote desktop backend) only supported 8-bit color, and might not work as well as desired for the serial ports. Thankfully, there was an alternative... (I know WinXP Pro would have worked, but it would have failed my multi-user requirement if both users wanted to be using at the same time.) I dug out this wonderful product called Citrix Metaframe XP Presentation Server. (3rd party remote desktop up the wazoo) Not only did it work with serial ports, but I even got login music (which I promptly disabled).

Now there was just one piece of the puzzle left... authentication. So I went ahead, and once and for all figured out how to get Windows domain-style logins running through my Samba server. Now all my normal "Logicprobe accounts" can also be used to log into this Windows machine.

(I'll have to set this all up again when I rebuild that SB1000 into a server, but at least I've done a test run of everything and know it will work.)

Ahh, the joys of geeking out...

2005-10-27T00:04:00.000-04:00

On Saturday I was visiting a friend of mine who recently bought a house over in the Winter Springs area. While there, I ran across a CD he had of a game from Sierra called Alien Legacy. I remember playing this game from hours on end, and it took me back.

So the next day, when at home, I decided to get out my bad-ass gaming box. This thing has specs that'll make you drool. The box is a loaded 486DX-33MHz with a whopping 16MB of RAM (probably worth about $800 retail), a fantastic Number Nine #9GFX VESA Local Bus (VLB) graphics card, Sound Blaster 16 sound card, and an Adaptec ISA SCSI card. That's right... Both the CD-ROM drive and hard drive are SCSI. I even wound up upgrading from the 400MB drive I was using to an enormous 2 "gigabyte" hard disk. And for the heck of it, I also decided to order a VLB SCSI card to replace the ISA one I had. This thing's definitely a screamer, and no idea how I got my hands on it :-)
Needless to say, Alien Legacy ran really well on it.

Oh, wait... It's 2005, not 1993... That machine's probably someone's old junk collection that they'd pay me to take away. :-D

Well, in reality, its a machine I decided to build a couple years ago with the goal of being the uber-dream-machine from 1993'ish, to run those old games really well. At this point, the only other upgrade I'd even consider would be for a 408DX2-66, simply because TIE Fighter can get jerky at times.

In any case, I also chose a fitting name for this machine... Phologiston.