January 2010 Archives

SQL is a great language for human query writers, but that has given it a bias toward a query->generic error.  It assumes that when you run a query and it returns an error, you are smart enough to know what query caused the error.  Easy if you are a human using a commandline.  Most SQL connection libraries just log the error, not the SQL that caused the error.  A simple production problem caused by a missing table becomes a two hour snipe hunt through the code to identify the SQL statement, and from there figure out the issue.

2010-01-09 11:15:50,935 ERROR [org.mindbent.audit-test] (ajp-0.0.0.0-8009-12) error performing audit
javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not get next sequence value

The error above is useless.

The easiest solution is to have a DB connection layer that adds some additional exception handling and logs what was being run, or a stack trace that actually links to the portion of your code that is the problem.  In JBoss/Java I think you could subclass the JDBC Driver (ie com.mysql.jdbc.Driver) put your own wrapper methods with better exception handling and then use the new class in your datasources.  I haven't tried this yet, but it seems like a convenient solution. 

More directly its better to log too much and have to turn the log level down than too little and have no way to turn it up.   

As another option, why can't the SQL server have a setting to log failed queries? (I understand Oracle does via connection tracing, to some extent)  Have to be careful about the security implications, but it could make some troubleshooting a lot easier.

I am writing code to talk to a Seiko S-35390A Real Time Clock (RTC) chip for the new Battery Management system I am designing for REVOLT Custom Electric Vehicles.  The chip communicates with my microcontroller via I2C, a reasonably well defined standard.  I2C,conveniently defines the bit order for data transmitted over the bus.  The RTC chip, for some reason, requires all of it's data to be sent as BCD encoded data with the bits reversed from the bus standard, (LSB becomes MSB.)  Reversing bits should be a textbook problem, but I found only a few clean ways to do it. There is probably an simpler way using 16bit shifts but here is a solution using a lookup table.

//Seiko RTC chip uses an annoying packing system where the LSB
// of the BCD represented data is in the MSB of the value
// that has to be written to the register.  This function
// does the bitwise flip of each nybble using a lookup, and
// swaps the two nybbles. 
unsigned char RTC_ConvertRBCD( unsigned char value ) {
    const unsigned char tobcd[] = { 0x0, 0x8, 0x4, 0xC,
      0x2, 0xA, 0x6, 0xE, 0x1, 0x9, 0x5, 0xD, 0x3, 0xB,
      0x7, 0xF };

    return (tobcd[value & 0x0F] << 4 ) + tobcd[value >> 4];
}

//Input is a 8bit number, returns the BCD encoded, bit reversed
// value needed by the Seiko RTC chip registers
unsigned char RTC_ToRTCBCD( unsigned char value ) {
    return RTC_ConvertRBCD( ( ( value / 10) << 4) + ( value % 10 ) );
    //return  RTC_ConvertRBCD( ( ( value / 10) << 4) + ( value & 0x0F) );
}

//Input is a bit reversed packed BCD register value from
// the Seiko RTC chip, return is a normal 8bit value
unsigned char RTC_FromRTCBCD( unsigned char bcdvalue ) {
    unsigned char unpacked = RTC_ConvertRBCD( bcdvalue );
    return ( ( unpacked >> 4 ) * 10) + ( unpacked & 0x0F );
}


Cool, and simple.  The Yubikey is a one-time password generator in a USB key.  Plug in in and it emulates a USB keyboard.  Touch the button on it and it will type out a one-time use password.  Basically the same system as "rolling code" garage door openers.

The hardware should be pretty cheap having no battery like the RSA SecurID tokens, just a microcontroller.   It claims to be somewhat resistant to phishing, though I cannot see how that works. 

The YubiKey

It works seamlessly with any hardware and operating system combination supporting USB keyboards such as Windows, MacOS, Linux and others. The Key generates and sends unique time-variant authentication codes by emulating keystrokes through the standard keyboard interface. The computer to which the Key is attached receives this authentication code character by character just as if it were being typed in from the keyboard - yet it's all performed automatically. This process allows the Key to be used with any application or Web-based service without any need for special client computer interaction or drivers.

The YubiKey differs from traditional authentication tokens based on time-variant codes in that it needs no battery and therefore does not rely on an absolute time generated by an accurate time source. No battery means unlimited shelf life, no synchronization and customer support issues, and enables significant cost reduction.

Link

I was writing a build script in Bash for one of the development projects and I wanted to have a list of patches that would be applied to a "clean" distribution of JBoss to create the fully configured app server.  I needed something simple so the development team could continue to maintain and update the script.  I came up with this idea while looking at RPM building.

#!/bin/bash

PATCH0=$SOURCES/jboss-4.2.3.GA.base.patch
PATCH1=$SOURCES/log4j-setup-append.patch
PATCH2=$SOURCES/jboss-set-call-by-value.patch
PATCH3=$SOURCES/add-security-policy-login.patch
MAXPATCHES=100  #The script searches for PATCH{value}= lines from zero to this number

echo "Applying patches"
i=0
while [ $i -lt $MAXPATCHES ] ; do
  PATCH=$(eval echo $echo PATCH${i});
  if [ ! "$PATCH" == "" ] ; then
    echo "Applying patch: $PATCH"
    patch -p0 < $PATCH
  fi
  i=$[$i+1]
done;


In the end it might have been simpler to use a datafile, or a language with Array support, but this works well enough and is fairly usable.

Cynical

There's never enough time to do it right but always time to blame the sysadmin. --Joe Thompson, in ASR