Category: Software

In the process of figuring out how to set up the isolated WiFi Internet link on the file server, I discovered that the /etc/rc.local file runs before the eth0 interface that connects to the outside world comes up. As a result, my DynDNS host address hadn’t been updated in quite some time.

Worse, trying to set up eth1 failed, apparently because there’s a bunch of other network infrastructure that doesn’t start until eth0 comes online. Part of that infrastructure involves iptables; the added rules simply vanished.

The solution seems to require writing an upstart script that waits for whatever events it needs, does what needs to be done, and then goes away. The whole upstart mechanism and its event list seems, um, lightly documented, as I discovered there, but the custom setup formerly in /etc/rc.local now lives in /etc/init/local.conf:

description "Stuff that used to be in /etc/rc.local"
author "Ed Nisley - KE4ZNU"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on shutdown

script

logger Starting local init...

logger Updating dyndns
ddclient -force

logger Bringing up eth1
ifconfig eth1 192.168.3.1 netmask 255.255.255.0 up

logger Setting iptables
iptables -A FORWARD -i eth1 --destination 192.168.0.0/16 -j REJECT
iptables -A INPUT -i eth1 --destination 192.168.0.0/16 -j REJECT
iptables -A POSTROUTING -t nat -j MASQUERADE

logger Ending local init

end script

That code assumes the outbound network interface will be eth0, which won’t work on a system using a pure wireless connection on, say, wlan0 or anything more exotic. I haven’t a clue how to parameterize that selection. Most likely, one would write another upstart script that would emit a custom signal based on the usual suspect …

It also assumes the networking infrastructure triggered by eth0 lighting up has hauled itself to its feet and is ready to roll. That seems to be true, although I’ll admit the script is, at best, lightly tested.

With the eth1 NIC up and iptables rules added, I think this script will restart eth1 when it goes down, but it’s not clear where the requisite network-device-down event comes from (certainly not from any script in /etc/init/*conf):

description "Restart eth1 when it dies"
author "Ed Nisley - KE4ZNU"

start on net-device-down IFACE=eth1
stop on net-device-up IFACE=eth1

script

logger Restarting eth1...
ifconfig eth1 192.168.3.1 netmask 255.255.255.0 up

logger Ending eth1 setup

end script

But, eh, at least the isolated interface comes up and packets go where they should (and not where they shouldn’t). Early results are encouraging…

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…