Building 32-bit openssl libraries with the Sun C compiler

This week I needed to install OpenSSL 0.9.8g on one of my servers. When I went to configure and build the libraries with the Sun C compiler, I noticed that 64-bit libraries were produced by default. It turns out that this is the default behavior if you try to build OpenSSL on a 64-bit platform. To build 32-bit shared libraries, I ran Configure with the “shared” and “solaris-x86-cc” options:

$ cd openssl-0.9.8g

$ ./Configure shared –prefix=/usr/local solaris-x86-cc

$ make

$ make install

There may be other ways to do this, but this method appears to work ok.

Monitoring the IPMI system event log

If you have a relatively recent server, your machine most likely supports IPMI. One technology that makes IPMI extremely useful is the baseboard management controller (BMC), which is an out-of-band controller that monitors the health of your server platform. Health monitoring is accomplished by distributing sensors throughout the server, and feeding the data these sensors collect back to the BMC. If the BMC detects a fault condition, it can log an error to the system event log.

The event log can be monitored by a number of IPMI software packages. Once such package is ipmitool, which provides the ipmievd daemon just for this purpose. If you are running a recent version of Solaris 10*, you probably already have the IPMI software and the ipmievd daemon installed. You can use the following commands to check:

$ pkginfo | grep ipmi
system SUNWipmi ipmitool, (usr)
system SUNWipmir ipmitool, (root)

If the software is installed, you can use the svcadm utility to enable the ipmievd domain:

$ svcadm enable svc:/network/ipmievd:default

Once the ipmievd service is enabled, you can use the ps and svcs commands to verify that the daemon is running:

$ svcs -a | grep ipmi
online 0:25:52 svc:/network/ipmievd:default

$ ps -ef | grep ipmi
root 328 1 0 00:25:53 ? 0:01 /usr/lib/ipmievd sel

If the daemon starts up, it will periodically poll the BMC system event log. If ipmievd detects an error condition, it will log a message to syslog. This message will contain details on the fault, which can be used to help determine that a server is sick. Since FMA currently doesn’t do platform health monitoring (the sensor project will fix this), ipmievd is able to step in and fill this role for the time being. Nice!

* This blog post assumes you are running Solaris 10 update 4 with patch 119765-06.

Finding bugs in Java programs

A while back I came across findbugs, which is a static analysis tool that can be used to locate bugs in Java programs. Findbugs is able to identify a number of bug patterns, which range from bad practices to performance and multithreaded programming bugs. Findbugs can be invoked through a graphical utility, or by running the findbugs command line utility. The command line option has the advantage that it can be easily incorporated into existing build processes (there are options readily available to integrate findbugs with maven and ant), allowing code to be tested when new builds are created.

To use the command line interface, you can run the findbugs executable with the “-textui” option and one or more options to control how findbugs goes about locating bugs. The following example uses the “-effort” option to tell findbugs to but the maximum amount of effort into finding bugs, requests that all bugs that are considered medium to high in priority be displayed, allocates 1GB of memory to findbugs, and sets the default output format to HTML:

$ findbugs -textui -effort:max -maxHeap 1024 -html -medium test.jar

Once findbugs completes its analysis, an HTML report similar to the ones on the findbugs website will be written to standard output. Since findbugs is free and can be easily integrated with several build tools, there is little to no reason that java developers shouldn’t use it to analyze their code for bugs. If your interested in learning more about findbugs or the bug patterns it detects, you should check out the findbugs website and the talk Bill Pugh gave at Google!

Generating byte code from a Java class file

I have been reading through the Java virtual machine specification, which covers all the details needed to implement a JVM. Once thing the specification talks about in detail is Java bytecode, which is the machine independent code that is executed by the virtual machine implementation. At various places in the specification I wondered what the byte code would look like for a chunk of Java code. Fortunately for me, the Java SDK comes with the javap utility, which can be run with the “-c” option to translate a class file into byte code:

$ javap -c -s -verbose MyEnv

  Signature: ()V
   Stack=1, Locals=1, Args_size=1
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."":()V
   4:   return
   line 3: 0

public static void main(java.lang.String[]);
  Signature: ([Ljava/lang/String;)V
   Stack=2, Locals=2, Args_size=1
   0:   new     #2; //class MyEnv
   3:   dup
   4:   invokespecial   #3; //Method "":()V
   7:   astore_1
   8:   aload_1
   9:   invokespecial   #4; //Method allocateObjects:()V
   12:  return
   line 7: 0
   line 8: 8
   line 9: 12

In the output above, you can see the methods and constants the MyEnv class utilizes, and the byte code that makes up the main method in the MyEnv class. Javap is amazingly cool, and I am starting to realize that understanding byte code can a super useful tool for debugging problems.

Printing a set of lines after a pattern match

I had to do some pattern matching last week, and needed a way to print the two lines that occurred after each line that matched a specific string. Since awk provides robust pattern matching, I came up with the following awk command line to grab the information I needed:

$ cat test
$ awk ‘BEGIN { i=0 } /foo/ { while (i < 2 ) { getline; print $0; i++ } i=0}' test

I digs me some awk!