I’ve been using KeePass for years to store my passwords for all the various sites, servers, etc. that I need to access. As such, I have liberated myself from having to remember any of them and can therefore choose entirely unguessable, randomly-generated passwords for highly-secure things like, for instance, accessing my online back accounts.

I tried to use such a password on an external disk I recently attached to my Mac running OS X 10.8. I generated a 128-character password and let the corestorage framework get started on the multi-day effort of encrypting a 3TiB drive. Then I disconnected the drive to relocate it and when I plugged it back into my Mac, I was asked for the password in a dialog. No problem: drag-and-drop from KeePass into the password-entry dialog.

That didn’t work: the password-entry dialog isn’t a text-drop-target.

Okay, no problem: copy from KeePass and paste into the password-entry dialog.

So I hand-entered the enormous password. Three times. All three times I must have screwed-up something. Maybe I thought an I was an l or a 1 or whatever. It doesn’t matter. It’s not going to work long-term: I’m simply not going to hand-enter a huge password whenever I want to access that disk.

Sure, I have to go through the extra step of going to the CLI to mount that external disk (after dismissing the passsword-entry dialog when first attaching the device) but a) I’ve got the CLI open all the time anyway and b) I get to use my super-secure password without having to hand-type it.

I’ve recently decided to move from CVS to Subversion, but I’m not ready to move everything at once. Thus, I have decided to move some things and save others for later. In order to do that properly, I need to make some projects in CVS read-only while allowing others to remain active.

A bit of Googling easily reveals how to make CVS entirely read-only (add an empty ‘writers’ file to the CVSROOT project or to make projects write-only on a project-by-project basis (by setting group file permissions on the server), but those techniques are too heavy-handed for me: I want some projects to be writable and I want to be able to check-out old copies of read-only projects. Neither of the above techniques will do that for me.

So, I looked-into something I should have known all about after running a CVS repository for nearly 9 years: the commitinfo file. You can read all about the commitinfo file online. I decided that since I could use commit-time “checks” to veto any commit for virtually any reason, I could certainly affect read-only access on a project-by-project basis.

#!/bin/sh
#
# This script is intended to be used as a failure script for CVS projects
# that are now in a read-only state.
#
# Configure this in CVSROOT/commitinfo like this:
#
# ^projectname/.* /path/to/script "%p" %s
#
# Or, to make all projects read-only, you can do this:
# DEFAULT /path/to/script "%p" %s
#
echo "========================================================================="
echo "Cannot commit the following files because '${1}' is now read-only:"
shift
while (( "$#" )) ; do
echo " $1"
shift
done
echo "========================================================================="
# Exit with a non-zero return code
false

The magic is all in the last line of the script:

false

This allows the script to exit with a non-zero status and therefore block the commit from occurring. This also allows all projects to be checked-out, updated, etc.: just no commits to those projects, which is exactly what I want.

Today, I was working with a colleague to generate a report in CSV format and she was having trouble opening it in OpenOffice.org’s calc (spreadsheet) program. She was getting the error “the maximum number of rows has been exceeded”, yet the file had only about 2800 rows in it. I tried it and got the same error. Hrm.

It turns out that the CSV file itself had an error in it: a mismatched number of ” characters in the file, which is not legal — or at least not a good idea. We fixed the code that generated the CSV file to properly escape those ” characters and all was well.

I’m posting this in the hope that others searching for answers will look at their files and see that there is a problem with them. There seem to be a bunch of sites and fora on the web where people ask these questions and don’t really get much of an answer, so this post may help those people.

Oh, and I should file a bug against OpenOffice.org calc saying that this is a really bad error message.

I’ve been using the Firefox 4.0 betas recently, and I just noticed that Firefox Sync is available without a plug-in. I had never used Firefox Sync before, but I currently have 32 tabs across 4 windows currently open in my 3.6.10 install and it would be nice to be able to open them all in ff4 and see how the performance is, relatively speaking.

So, I installed the plug-in into 3.6.10 and restarted Firefox. I clicked on the sync button in my status bar and I was asked to fill-out the registration information. I always use KeePass for everything, so I created a new entry in KeePass and had it auto-generate a password. I tried dragging-and-dropping the password from KeePass but the “Next” button in the registration wizard remained grayed-out and unclickable. Weird. I tried typing a few things and got “too short” and “mismatched password” messages, so I tried good-old copy-and-paste and finally got it working. 😦

I created an encryption key and appeared to get everything sync’d with the server. It’s tough to tell that it worked, because there is no feedback. Oh, well. The proof will be when ff4 grabs all those tabs and loads everything.

So, I go over to ff4 and click the sync icon in the status bar. I choose “I have used Firefox Sync on another computer” and it asks for my username and password. I enter my email address as my username and the password from KeePass, and get an error: Incorrect username and password.

Boo.

I check everything out, and I haven’t made any mistakes: I copy/pasted everything and it’s still not working. So I get smart and navigate to about:config in both browsers. I search for keys like ‘sync’ in both and notice that there are a bunch of non-default values in 3.6.10 that aren’t set in 4.0b. Not surprising. I start to read through them. I tried to set ‘services.sync.account’ to my email address to trick ff4 into thinking I had set up sync so I could just go in and modify whatever I wanted using the “Sync Preferences” interface. No luck.

I noticed further down that there is a ‘services.sync.username’ key (the last one alphabetically, so I didn’t notice it at first’ and the value is some crazy thing I’ve never seen before. So, I copy that thing from Firefox 3.6.10’s about:config into the username field in the setup wizard in 4.0b, click “Next” and it accepts the password. Next question: what should happen on first sync? I choose “replace this computer with the sync server’s contents”: I want to get all my 3.6.10 stuff into 4.0, and I don’t care what I have already in 4.0.

I press the sync button and I get a message: Error while syncing. Looking in the Error Console, I can see it says “2010-10-14 17:53:54 Service.Main WARN Upgrade required to access newer storage version”. Fantastic. I evidently have the latest version of the Add-On in 3.6.10 and the latest built-in in beta (4.0b6) and they are incompatible.

Again, Boo.

So, I start looking at about:config again. services.sync.lastversion=”@weave_version@” in 4.0b. That looks like an RCS replacement string. In 3.6.10, it’s set to “1.5”. I try manually setting it to “1.5” in 4.0. No dice.

Evidently, since I’m using Portable Firefox, I’m a version behind and therefore incompatible with the version of the Add-On I just installed into 3.6.10.

Sigh.

I’ll see about upgrading. At least it didn’t completely toast all my tabs, etc. Just in case, I’ve already made a backup copy using the Session Manager add-on which has saved my digital life several times over.

Update: So, Firefox 4.0b7 didn’t ship at the same time as Firefox Sync 1.5, so the beta is now out-of-date. Looks like an upgrade to the add-on should work? Sounds counter-intuitive.

Update (2010-10-15): I installed the Firefox Sync 1.5 plug-in into ff4.0b and restarted the browser. I re-configured the sync (which looked a lot like the process built-into ff4b6 already, and not the process that I went through with the plug-in over in 3.6.10) and I’m still getting the same error. All advice I can find online is to install the plug-in into 4.0b6, but it appears that the plug-in doesn’t get used. Still waiting for 4.0b7. 😦

I recently because aware of a problem in CHADIS where our SVG images weren’t styling correctly in print previews: everything was black-and-white, except for a particular image that seemed fine. This was observed in MSIE 8 with the Adobe SVG plug-in, and also in Microsoft’s new MSIE 9 platform preview. Actually printing the image had the same problem as the print preview: no color.

The difference appeared to be that the working image had a completely in-line set of styles, while the broken images were referencing an external stylesheet. We confirmed that moving all the styles into the main image resolved the problem. That defeats the whole purpose of having an external stylesheet: sharing. At least we had a workable solution that we could implement if absolutely necessary.

I checked-out Adobe’s FAQ, and they claim to support external CSS files for SVG files. Weird. I looked at the files, again, and noticed that we were using a stylesheet that didn’t have a fully-qualified URL: it was a relative one:

<?xml-stylesheet href="/path/to/stylesheet.css" ?>

On a whim, I hard-coded a hostname into the stylesheet’s URL and, lo and behold, the stylesheet was loaded. This trick works on both the MSIE 9 preview as well as MSIE 8 with the Adobe SVG plug-in.

It’s unclear to me whether this is an MSIE problem (that the base URL isn’t properly set during printing) or an Adobe problem. Given that it occurs in both MSIE 8 with the Adobe plug-in, and MSIE 9 without the plug-in, I suspect it might be a fault in MSIE in general. In either case, only MSIE requires the Adobe plug-in these days, anyway, so it doesn’t matter whose fault it is. The solution, however, is to fully-qualify the URL for the stylesheet:

Yeah, that’s a long title, but I want it to be easily searchable on the web.

I have an Intel-based Mac Mini running Mac OS X Tiger. I recently procured a Snow Leopard DVD and read that you can, in fact, upgrade from Tiger to Snow Leopard. Snow Leopard has some cool new features that I thought I’d like, so I gave it a shot.

I inserted the DVD and the finder window came up showing me the “Install Mac OS X” option and I double-clicked on it. It told me it had to reboot in order to perform the installation, so I said okay and it rebooted.

(Note that I didn’t care what happened to my existing installation, files, etc… this machine is used for web application testing, so I don’t care if I wipe everything or not).

After a few minutes, the installer came up and asked me what language I wanted to use (English) and I continued the install. It thought about things for a while and then told me:

Mac OS X cannot be installed on this machine because it does not have enough memory.

My options at this point were: Restore from Backup and Reboot. I chose the latter, thinking that the DVD would eject and I’d be back to using my old Tiger install.

Instead, the DVD stayed in the drive and, after the reboot, the whole process repeated — basically, I was asked what language I wanted and then told that my computer didn’t have enough memory to install Snow Leopard. 😦

So, I tried the most obvious thing any Mac user would do: I pressed the eject button on the keyboard. No dice. I held the eject button down for what must have been 2 minutes. Nothing.

I tried Googling for answers. Lots of people giving various suggestions, none of which was working for me. CTRL-COMMAND-O-F apparently doesn’t work on Intel Macs. Holding OPTION during boot did nothing. Holding EJECT did nothing. Holding the mouse button down did nothing. I was seriously contemplating cracking open the machine to extract the DVD.

Someone suggested plugging the mouse button directly into the Mac, because some USB hubs don’t work quite right at initial boot. I have a Mac keyboard with my mouse plugged directly into that. That’s about as directly-plugged as you can get, right?

Well, apparently not. I moved by USB mouse from the keyboard to the back of the Mac Mini and held down the mouse during boot. Voile! Out popped the DVD.

So, anyone having similar problems can try this trick. It may save you from tearing-open your Mac Mini, or tearing-out your hair.

One of my favorite Mozilla Firefoxadd-ons has always been LiveHTTPHeaders: you can observe the HTTP headers being sent to and received from the server when a web page is requested. You can even have it record a bunch of requests as you click through a site to see the entire series of transactions.

One of the problems I’ve always had with LiveHTTPHeaders is that the project owners take their sweet time when it comes to new releases. For example, Firefox is currently on its 4th beta release of version 3.5 and yet LiveHTTPHeaders only works on versions 3.0.x.

I keep checking the project site for that magical “works with 3.5 beta”, but it never comes. The top comment on the addons.mozilla.org project page is currently

Does all I expected it to do—and does it wonderfully. Wish it was compatible with FF3.1.

Today, I decided to do something about it. I’ve never poked inside a .xpi (“zippy”) file (the file format for product Mozilla add-ons) so I did some reading on Wikipedia. Turns out it’s just a ZIP file. If you open the ZIP file, you can see a series of files including install.rdf. RDF is just XML, so I checked out the contents of that file. The install.rdf file contains a bunch of information about the package itself, including the list of supported versions of various products (including Firefox, Flock, and Seamonkey). The setting for Firefox was

<em:maxVersion>3.0.*</em:maxVersion>

On a whim, I simply changed that to

<em:maxVersion>3.5.*</em:maxVersion>

and installed the .xpi into Firefox.

A quick ff restart later and it’s now working, apparently without any problems. Woo hoo!

I’m an active member of the Tomcat-users mailing list and I see lots of folks that post questions about not being able to get a new database connection. The answer is simple: you have exhausted their JDBC connection pool. The answer is not so simple because the reasons for the situation can often be different, but most likely, your application is not properly handing pooled connections. Read on for information on how to code your app to properly handle such pooled connections.

In CHADIS, we had a requirement to indent certain <option> elements within a <select> dropdown list. Until recently, only team administrators had to use these pages, so we just made it work in Mozilla Firefox and left the other browsers out in the cold. Now that we have some new features that need this capability, I decided to write-up a quick page to demonstrate each technique we tried and how each browser renders them. You can see the investigation and results below. Enjoy.

I use Ubuntu on a server I use for software development over a VNC session. This is how I learned to do Java software development way back in 2000 at one of my first jobs, and the habit stuck. I recently upgraded to Ubuntu 8.04 LTS (via a completely straightforward and painless upgrade process, I might add) and noticed that something strange was happening: after entering my ssh key password once in a session, I was not asked for it again. Ever.

I leave myself logged into this machine for months at a time, and I never lock it. The only locking you might consider is that I disconnect from the VNC session and re-connecting requires a password. However, I have access to some sensitive information for my job and I’m a little leery when I’m allowed access to things unchallenged.

First, I thought something really fishy was going on, until I started reading man pages and doing a little digging. I found out about ssh-agent (which I had previously never heard of, since I’m usually using command-line-only interfaces) which did not appear to be running. Oddly enough, using ssh-add to flush all cached keys did work, so I was certain that the ssh-agent was lurking somewhere — I just hadn’t found it, yet.

Finally, today, I got fed up and apparently entered the magic phrase into Google. The reason I couldn’t see it running is because the process is gnome-keyring-daemon, not ssh-agent or *agent* or even *ssh*, which makes it tough to find if you don’t know that it’s a gnome component that is performing this service. I found the answer in the Gnome Keyring SSH Agent page on the Gnome Live website. Instructions for disabling ssh key caching are on the page here.

One thing they missed is that you can use gconf-editor to tweak the value indicated in the gconftool-2 instructions. Also, you can change the behavior of a running Gnome system by doing a ‘kill -HUP’ on the existing gnome-keyring-daemon process, and then re-starting it with the ‘–components’ that you want (i.e. removing the ‘ssh’ service).

Now, I get to enter my password every time I make an ssh connection, just as it should be 😉