Monday, May 24, 2010

jTDS for dummies

I got this error when trying to use a MS SQL data source in Confluence:

Cannot load JDBC driver class 'net.sourceforge.jtds.jdbc.Driver'

I had downloaded the jTDS JDBC driver (or so I thought) and put it in the common/lib folder of my Tomcat installation.

What I had done wrong is I downloaded the jtds-1.2.5-bundle.jar file thinking it was the MS SQL connector I needed. Apparently I should have downloaded the jtds-1.2.5-dist.zip file, extracted jtds-1.2.5.jar from that, and copied that file to my Tomcat common/lib folder.

Friday, May 21, 2010

balsamiq

I just stumbled upon this really cool program for creating UI mockups called Balsamiq. I'll let the pictures speak for themselves. You can also play with it online:

http://www.balsamiq.com/builds/mockups-web-demo/

One possible open source alternative is called the Pencil Project, but it looks like it's maybe got a little too much going on. One of the main things Balsamiq has going for it is it only takes a couple of minutes to slap together a mockup. You definitely don't want to be spending more time on your mockup than you have to, taking away from time spent actually implementing it.

One promising alternative, which is free and web-based is Mockingbird. It uses Javascript, and it's pretty nice.

Balsamiq examples:



Thursday, May 20, 2010

Heimdal 1.3: BAD_ENCRYPTION_TYPE

Solution:

Edit the Kerberos configuration file (for me it's /etc/krb5.conf), and add this line in the [libdefaults] section:

allow_weak_crypto = true

Details:

More of the same... (see my posts on Berkeley DB) I compiled the latest version of Heimdal Kerberos the other day (it's the recommended flavor of Kerberos to use with OpenLDAP), and after getting everything set up, I would get these errors when trying to run LDAP searches:

SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:  Miscellaneous failure (see text) (encryption type 2 not supportedt))

(sometimes it also said encryption type 1 not supportedt, again with the t on the end of supported)

My first thought was maybe I didn't have a valid Kerberos ticket, but when running kinit, I would get this:

kinit: krb5_get_init_creds: BAD_ENCRYPTION_TYPE"

Google searches on those terms didn't get me far, but after looking through the Heimdal documentation, I realized they deprecated support for DES encryption in Heimdal 1.3. The solution I discovered for enabling it again is posted above.

Et voila! Back in business.

More information: DES will die in Heimdal 1.3

Wednesday, May 19, 2010

Compiling Berkeley DB on GNU/Linux

When compiling Berkeley DB on GNU/Linux (in particular if it's being compiled to be used with OpenLDAP), make sure you compile it with the following flags:

--enable-posixmutexes --with-mutex=POSIX/pthreads

I happened to run across that buried in the openldap-software mailing list archives. Here are some more details:
"On x86 though, they have a hybrid mutex mechanism which is enabled by default. It uses both assembly language spinlocks and pthread mutexes, first spinning in the assembly language lock some number of times before falling back onto the mutex. They claimed that this improved performance in their tests, because pthread mutexes can be very expensive on some platforms. In my tests on x86_64 Linux however, it just forced CPU usage to 100% (200% actually, dualcore) and slowed down overall throughput.

You can give an explicit "--with-mutex=POSIX/pthread" argument when configuring BerkeleyDB to avoid the hybrid mutex scheme"
http://www.openldap.org/lists/openldap-software/200708/msg00344.html

"BerkeleyDB will use excessive CPU on Linux unless you configure --with-mutex=POSIX/pthreads. By default it uses "hybrid" mutexes, which use an assembly language spinlock loop before falling back to pthread mutex. The spinlock will chew up all of your CPU on multiprocessor machines..."
http://www.openldap.org/lists/openldap-devel/200809/msg00085.html

More:
http://www.openldap.org/lists/openldap-devel/200902/msg00064.html
http://www.openldap.org/lists/openldap-technical/200906/msg00015.html