Tag: Improvements

My Zire 71 stores all my userids, passwords, credit card numbers, and similar sensitive bits in a convenient offline package, using the obsolete Palm gnukeyring app. The KeePass app on my Kindle Fire can, in principle, do the same thing. Minus the convenient and offline parts, that is.

So the problem becomes how to export about 150 entries, each containing at least one character string carefully chosen for maximum obscurity and typing difficulty, from the Zire to the Kindle. Ideally, there’s no retyping involved and it’d be nice to not leave the unencrypted contents lying around for very long.

This has a remarkable number of moving parts…

It turns out gnukeyring can export each entry into an unencrypted Palm Notepad file through a manual operation, but the cough user experience on the Palm goes something like this:

• Start gnukeyring, select entry-to-export
• Select Options, pick export to Notepad
• Notepad automagically starts up with the new note selected, so close it
• Exit Notepad, return to Home
• Iterate

That gets old very quickly, not to mention that the Notepad file uploads to the PC in the Palm’s slightly binary PDB format that’s basically useless without further hackage and exposes the passwords in unencrypted form.

Inter-app cutting and pasting on the Kindle is exceedingly tedious, because each app runs more-or-less independently in full-screen mode: it is not feasible to manually transfer the database one field at a time. So we’re looking at a PC-based solution.

There’s a Java utility that can export the whole encrypted Palm file into spreadsheet CSV format, putting each entry into a separate row and each field into a separate column. OpenOffice / LibreOffice can read the resulting file with no problem. Ctrl-A will select the entire Comment field for each entry, which means I can transfer that in one shot.

It can also export into an XML file, which seems more useful.

The utility is a command line thing, with an invocation something like this (use .csv to get that type of output):

java -jar export.jar Keys-Gtkr.pdb ‘password’ output.xml

As it turns out, my password contains an exclamation mark and Bash requires fancy escaping (the usual single or double quotes don’t work, because the exclamation mark has higher priority):

java -jar export.jar Keys-Gtkr.pdb Fancy\!PassWord\! output.xml

The XML files have this overall structure:

<U+FEFF><?xml version="1.0" encoding="UTF-8"?>
<pwlist>
<pwentry>
  <title>A useful name</title>
  <category>Web</category>
  <notes>The collection of
notes, asides, and suchlike
in a multi-line format.
</notes>
  <lastmodtime>2000-01-01</lastmodtime>
</pwentry>
</pwlist>

Notice that each entry contains its category, which makes a certain sense.

On the KeePass side, there exist Windows and Linux versions of KeePass, although one must be careful to use the 1.x level of the database on Windows, because that’s all the Android and Linux versions know about. It can import XML files and turn them into a database with a unique password; it cannot add entries from an XML file to an existing database.

KeePassX (the Linux version) XML files looks like this:

<!DOCTYPE KEEPASSX_DATABASE>
<database>
 <group>
  <title>Internet</title>
  <icon>1</icon>
  <entry>
   <title>The Entry Title</title>
   <username>your userid goes here</username>
   <password>the mystery password</password>
   <url>example.com</url>
   <comment>Presumably multiline comments work OK</comment>
   <icon>0</icon>
   <creation>2012-05-08T18:48:11</creation>
   <lastaccess>2012-05-08T19:00:49</lastaccess>
   <lastmod>2012-05-08T19:00:49</lastmod>
   <expire>2999-12-28T11:59:59</expire>
  </entry>
 </group>
</database>

KeePass puts the entries within overall groups, the inverse of the Palm gnukeyring structure. I suppose there’s a way to undo that manually, but … drat!

So, back to CSV. Although OpenOffice Calc can’t export XML directly, there’s an extension for that. Given a spreadsheet like this:

asdf	dfg
1	2
3	4
5	6

The XML file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ooo_calc_export scriptVersion="2.2.0" scriptUpdate="2010-12-19"
                 scriptURL="http://www.digitalimprint.com/misc/oooexport/"
                 scriptAuthor="vjl">
   <ooo_sheet num="1" name="Sheet1">
      <ooo_row><asdf>1</asdf><dfg>2</dfg></ooo_row>
      <ooo_row><asdf>3</asdf><dfg>4</dfg></ooo_row>
      <ooo_row><asdf>5</asdf><dfg>6</dfg></ooo_row>
   </ooo_sheet>
</ooo_calc_export>

Missing entries generate empty <column-name></column-name> sequences and embedded newlines produce multiline comments.

So the overall plan:

• Convert Palm database into CSV
• Import into OpenOffice Calc
• Change column names to match KeePass fields
• Add creation field with current timestamp
• Add expire field to celebrate the next millennium
• Sort by Category, delete Category column
• Export to XML, open in text editor
• Clean up header & footer tags to suit
• Insert group tags for category
• Change ooo_row tags to entry tags
• Import as new KeePass database
• Transfer to Kindle Fire
• Iterate until it works

While I had the file pinned down in the text editor, I cleaned up some cruft and moved userids / passwords from comments to the appropriate fields.

I hadn’t used the gnukeyring password field to avoid overwriting an existing password by mistake; that disaster always lay just two screen taps away. It’s a little harder to do on the Kindle, but …

And then it Just Worked…

Amazon obviously designed the Kindle Fire as an extension of their on-line store: they stripped everything out of Android that could possibly get in the way of buying stuff. Some functions seems obviously necessary, though, so here’s a short list of what I’ve added so far (in addition to the button protector and speaker seals, that is), with all the links collected for reference.

First and foremost, set a Lock Screen Password. Yes, that means that you must type the password every time the Fire lights up, which is a major nuisance. Remember that the Fire connects directly to your Amazon One-Click account and the browser has the rest of your userids & passwords on tap, so losing it could be a very, very expensive oversight.

I like 24 hour clocks, but there’s no clock configuration. Dropping a buck on 24 Hours solves that problem.

My old Zire 71 reminded me of my few appointments & things-to-do, but the Fire lacks the whole Android calendar infrastructure. The Calengoo app syncs with my (previously unused) Google Calendar & Contacts, which means that they now know my social network (such as it is) and what I’m up to. So it goes…

The system volume control exposes only the Media Volume sound channel. Calengoo produces reminders through the Notification sound channel and, under certain perverse conditions that took me about two days to encounter, can mute that channel and leave it muted forever more. The only way to get audible reminders again is by installing a separate mixer app and resetting the levels: Volume Manager Free.

Hint: to get dependable audible reminders when the Fire is asleep (which is most of the time), you must enable Pop-up Reminders and disable Pop-up windows, because the dialog box occasionally kills the sound. With that configuration, you’ll get a note in the status bar along the top of the display for each reminder. Set the reminder repeat interval to at least a minute to have enough time for password typing…

The main reason I got a Fire was to carry all my datasheets & manuals in my pocket, hence the need for color and a backlit screen. Although the Fire can handle PDFs without an app, the native interface leaves quite a bit to be desired. Dropping a few bucks on ezPDF Reader solves most of those problems. Choosing a single file from a collection of several hundred, using a selection browser that ignores the overlaid subdirectory structure, remains challenging.

File Expert helps a bit by presenting subdirectories and their contents. I think that might be the only way to find a specific PDF.

Engineering bears need an RPN calculator, of which NeoCal Lite seems to be the best of the bunch.

Passwords go in KeePassDroid, although it has a clunky clipboard interface to other apps. Of course, any Android app can root the Fire and steal my sensitive bits; that seems to not bother anybody else, so why should I worry? The advantage of using a unique password for each website seems to outweigh the disadvantage of having a single password controlling all of them.

Turn off the browser’s helpful “remember passwords” function, though…

Although I’m now using Dropbox to back up the KeePassDroid database file, that whole interface seems overly awkward and I’d rather have encryption applied to every Dropbox file.

Putting the KeePassDroid database file in the Dropbox folder requires a bit of intervention, as KeePassDroid provides no way to specify the database location. You must find the Dropbox folder using File Expert, slow-click the database file, then drill down through File Expert’s menus in order to specify that KeePassDroid should open the file. After that, KeePassDroid will remember its location. For future reference, it’s at:

/mnt/sdcard/Android/data/com.dropbox.android/files/scratch/keepass.kdb

The alert reader may wonder why a Kindle Fire, with a conspicuously missing SD Card slot, has an sdcard subdirectory structure hanging from /mnt: that’s just the way it is. I suppose that’s baked into the Android filesystem; hooray for hardware independence and futureproofing.

The built-in Silk browser runs slower (certainly, no faster) with Accelerate Page Loading turned on, so there seems no compelling reason to sluice my web content through Amazon’s servers. Not that turning it off improves privacy, of course.

The Maxthon Mobile Web Browser works reasonably well. The highly regarded Dolphin HD browser isn’t available from the Amazon App Store and sideloading apps from Google Play seems unreasonably difficult. The Firefox Aurora browser isn’t quite ready for prime time, but is the only browser to cover its password database with a master password.

For the occasional times when I need a stopwatch or timer, the aptly named Stopwatch and Timer app should suffice. It has a breathtakingly awkward UI compared to the Zire app, showing that re-invented wheels sometimes sport square corners…

ColorNote supports both checklists and text notes for my simple needs.

Sketch-n-Draw ably demonstrates the Fire’s huge latency between touch-pad input and LCD output; it’s impossible to actually draw anything meaningful. FWIW, the ancient Zire had no trouble doing that, adding Yet Another data point to the curve of software demanding more than the hardware can provide.

The WordPress blogging app is pretty much useless in comparison with their full web interface, not to mention that typing text on the Fire’s one-finger (or, for those with smaller hands, two thumbs) keyboard is agony, not to mention that the Fire lacks a camera, a microphone, and USB host support. It’s a media consumption device, not a media production device; I knew that when I bought it.

Although it’s awkward, a conductive-tip Acase stylus helps during extended screen-poking sessions. I have my doubts about the rubbery tip’s durability, though.

All in all, the Fire seems serviceable…

The default Grub2 video mode for Ubuntu 12.04 is 640×480, which looks rather overwhelming on a 24 inch monitor that can do 1920×1600. I’m also a fan of Old Skool scrolling text, because when something goes wrong it’s handy to get an actual hint in real time.

Thus, some Grub tweakage was in order:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

 ... snippage ...

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
#GRUB_GFXMODE=1600x1200
GRUB_GFXMODE=1280x1024

AFAICT, it’s impossible to:

• Page(*) the output of the Grub vbeinfo command. A blind stab at 1600×1200 turned out to be too small and painfully slow at scrolling in graphics mode.
• Boot a text-mode console in anything other than 80 characters x 24 rows, so un-commenting the GRUB_TERMINAL line isn’t helpful.

This being Grub2, you must do this special dance (anybody remember when one of Grub’s advantages over Lilo was that it didn’t require a special dance?) to make it work:

sudo nano /etc/default/grub
 ... make changes & save ...
sudo update-grub
sudo reboot ; exit

That’s from an SSH session across the room, of course…

Incidentally, shutting off the graphic drivel immediately revealed that those NFS mounts weren’t happening because statd wasn’t running. Knowing that immediately would have saved some diagnostic time, yes, it would.

(*) The Official Grub2 doc suggests set pager=1, but there’s no way to discover that using help set at the Grub2 command line. Now we both know and maybe we’ll remember it for the next time.

Back in the old days, the Unix startup sequence was rigidly fixed. For a variety of reasons, that’s no longer the case; Ubuntu (and, presumably, other distros) now use upstart, which turns the startup sequence into a lightly documented Pachinko machine. This parallel processing presumably works great for most of Ubuntu’s use cases and falls flat on its face for me: I’m apparently the only person who expects NFS mounts to be in place before signing in.

Well, maybe other folks expect that, but the entire startup mechanism is apparently broken as designed.

The only solution seems to be stalling the user sign-on screen by jamming the display manager until the NFS client hauls itself to its feet. This takes up to a minute, for reasons I do not understand, but it’s better to let it run to completion rather than signing on and expecting one’s files to be in the right places. Email clients, in particular, have difficulty coping with missing files.

The fix involves adding a line to /etc/init/lightdm.conf, as mentioned there (albeit with incorrect syntax):

start on ((filesystem
           and runlevel [!06]
           and started dbus
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udev-fallback-graphics)
           and mounted MOUNTPOINT=/mnt/bulkdata)
          or runlevel PREVLEVEL=S)

I tried to check for another filesystem that should also be mounted, but, as I understand neither the syntax nor the semantics of the language, what you see is what finally worked. As it turns out, upstart's syntax error messages aren’t particularly helpful; a single line (helpfully relating, perhaps, that the parser expected a token on line 16) appears on VT 7, but if you don’t know to switch from VT 1, you’ll never get even that minimal assistance. No, such errors don’t appear in the /var/log/upstart/* logs.

For unknown reasons, waiting for the remote-filesystems event didn’t delay the startup at all. Evidently, mountall emits that event almost immediately, long before the NFS mounts happen. Perhaps the event occurs even when the mount fails, contrary to what the doc suggests?

Most of the debugging occurred through an ssh session across the room. Edit the file, try a new version, reboot, watch for the filesystems to come up, watch for the sign-in screen to appear. Or not, as the case may be.

Grumpy though I may seem, the great thing about Open Source / Free Software is that when it breaks, you have access to all the pieces and can actually fix the problem. That makes up for nearly everything, I’d say.

No, I didn’t update any of those bug reports or start another one. It’s obvious this isn’t getting any attention, so what’s the point? If you’re also having the problem, you’ll eventually wind up here…

FWIW, I knew the NFS mounts weren’t working because I always set the screen background to an image on the file server: no mount = no picture = fix-the-problem-now. This image seemed appropriate:

Back then, transistors were countable resources…

[Update: The previous picture link, now broken, was to http://www.nasaimages.org/luna/servlet/detail/nasaNAS~2~2~2995~104520. The revised link points to a description on archive.org, with versions of the picture available for download.]