OpenSSL to Java keystores

I've been creating SSL configurations for various groups in the company, and since I like the standard command line, I've been doing it via OpenSSL. However, some groups use Java-based SSL servers that need their .key and .cert in the Java Keystore format.

So to get the whole instruction set together in one place,

openssl genrsa -out servername.key 2048
openssl req -new -x509 -key servername.key -out servername.csr
#
#Send off the CSR to get it signed, and pull down the intermediate CA certificates that our internal authority uses to sign.
#
openssl pkcs12 -export -in servername.cert -certfile intermediate.cert -inkey servername.key > servername.p12
#Give it a password at least 6 characters long so that Java doesn't complain
keytool -importkeystore -srckeystore servername.p12 -destkeystore servername.jks -srcstoretype pkcs12

Yet another annoyance

I tend to keep a lot of stuff on my hard drive. Modern drives are big, and modern filesystems don't have a problem with searching through long, fragmented free lists that made the old suggestion of "keep the disks less than 90% full" smart. I defrag occasionally, and (at least on my laptop) a high-speed SD card configured for Readyboost to improve application-launch induced disk seeks.

So I've been getting popups (no, not malware) for several months reporting that I'm running out of disk space. These are Windows-looking officialish "Warning Event Notification" popups, reporting that "disk free space has fallen below the configured threshold." Annoying, displays in the center of the screen (even when locked/logged off) and takes focus from my work.

It turns out this particular message is caused by the Dell OpenManage Client utility that the company uses to set the BIOS password for the system, and it's controlled by a registry key: HKLM\SOFTWARE\Dell\OpenManage\Client\SysInfo\HDDThresholdValue. I set it to 0 to get rid of the messages entirely.

--Joe

Listening ports

One of our many applications wouldn't start, with an obscure message that had nothing to do with the underlying problem (nsrexecd "Cannot start portmapper", to be specific and to make sure this is googleable for the next person)

It turns out that another process had been randomly assigned the ports that Networker had to listen on, to an outgoing TCP connection. Which, of course, meant that Networker couldn't bind to those ports to LISTEN. This is the first time this has happened. But it's a potential time bomb for any service that listens on specific ports. Such as Oracle, Weblogic, SAP, etc.

Linux controls what ports are randomly assigned using two sysctl's, ip_local_port_range and ip_local_reserved_ports. Unfortunately, the Oracle installer prerequisite check requires that ip_local_port_range be set wrong (1024-65500, which includes their own listener port) so we have to work with the other one, ip_local_reserved_ports. It's a "comma-separated list of ranges", so for us, I picked an excessive range for our big 3 applications- Oracle (1520 - 1530), SAP (3200 - 3699), and Networker (7937 - 8065).

sysctl net.ipv4.ip_local_reserved_ports=1520-1530,3200-3699,7937-8065

--Joe

Scanner characterization (free) to correct the colors in scanned pictures

I'm working to get my non-digital life in order by scanning in the large underbed box of photos that I've accumulated, but I've noticed that the color isn't quite right on the scanned images. The scanner "autocorrect colors" checkbox doesn't seem to help. I figure the best way to deal with it is to scan the pictures without any scanner-based color correction, and then apply a proper color modification to the resulting image. But the challenge is in 1) convincing the HP "easy scanning" junk to just give me the bits, and in 2) mapping the colors that the scanner sees to what's on the print.

Now, I could spend $60+ on a standardized color card, and use an expensive program to generate a color profile that could be applied to make the correction. But come on, it's just software. Instead, I am sending a color card I generated to the local Walgreens.com in-store pickup, and I'll use that to characterize the scanner. There's a toolset called Argyll that seems to do what I want, but it's not exactly the clearest documentation for someone who doesn't do digital image workflow for a living. But here's what I've figured out so far:

There's a zip of Windows executables. They seem to run on my Win7 laptop.

First, we generate a "target".

targen -v -d 2 target

This gives us a "target.ti1" (that's a one, btw) file.

Second, we turn this ti1 file into a TIF image (and at the same time we make a .cht map of the image that the tool will later use to recognize the image)

printtarg -i SS -v -a .4 -t 300 -p 4x6 -s -m 10 target

This gives us target.tif, and target.cht (and whatever target.ti2 is)

Third, since Walgreens only deals in .jpg files, I convert it to a 100% quality jpeg via GIMP. And I end up with a 336k file to have printed.


And now I'm waiting to pick up that picture.

Before I found the Argyll software, I had grand plans of figuring out the formulas to do the transformation myself in gimp. I made my own blocks of color, got them printed, and discovered that the transformations required to map the resulting RGB values to their originals was, well, let's just say complicated. Probably there is an easier formula in some other color metric (HSV or CMYK or something) but that's a lot of work to figure out.

My next attempt was with Argyll, but I thought the hexagonal color pattern was nicer than the color bars that come out of the default TIF. Unfortunately, Argyll won't create a CHT file to recognize the hexagons. So that was another $0.20 wasted. Oh well.

More to come.

--Joe

Link aggregation in a cross-platform environment

Everybody in the world knows that LACP (802.1ad) is the standard for Link Aggregation and Control, right? Well, not exactly.

We have VMware ESX and Solaris servers connected to our Cisco edge switches. Sounds good, right? We'd like to bond the multiple gig-E NICs into a multi-GB aggregate. Sounds good, right? Well, it's not so easy.

ESX doesn't support true 802.1ad aggregation. They fake it with their vSwitch NIC teaming properties. They do the same thing as L3 LACP (hash of the source and destination IPs) but don't call it that. Fortunately, they use the same hash algorithm as Cisco, so we can work with it.

On the cisco side, we add the interfaces to a channel-group with mode "on". This uses the default-for-the-switch port-channel load-balance setting, which we had to set to src-dst-ip.

Unfortunately, since that setting is a global switch option and is not set on a per-port-channel level, this means that our Solaris boxes (who speak LACP properly) can't use Layer-4 (hash of source and dest IPs and ports) balancing. This sucks, because our Solaris boxes are the heavy-network-hitters (backup servers) that could really use the extra bandwidth provided by spreading the multiple TCP connections across multiple links.

I'm not sure who to blame here, VMware for not doing LACP, or Cisco for not allowing multiple loadbalancing methods on different port channel groups.

--Joe