(trey’s take)On sharing a directory with Windows…

Market forces have conspired into forcing me to have a bare-metal Windows install (a Virtualbox Virtual Machine can no longer cut it). I still would rather work solely in Debian, or some form of Linux distribution (distro!), but this presents me with an opportunity to grow my skills in ways I did not anticipate. First, the scenario:

  1. I use the venerable KeePassX to manage my passwords. It is not to be confused with KeePass. Both programs have similar functions, and even read the same database format (KeePass 1.x), but the latest (and currently maintained) KeePass version depends on .NET, so on Linux that means Mono. Last I checked (which is admittedly a long time ago), the Linux/Mono port looked *terrible*. Luckily, KeePassX has a port for Windows, so I can keep the same look and feel regardless of whether I’m booted into Windows or Linux. FULL DISCLOSURE: KeePassX 0.4.3 has been out for some time, and it appears the development on the next version of KeePassX has slowed to a crawl or is nonexistent.
  2. No matter which computer I’m using, I want to be able to access the password database. In Linux, I just set up a port forward on my WAN router that points to the SSH port on my Debian workstation, and on my satellite devices I use SSHFS to mount the keepass directory. This “tricks” KeePassX in thinking the password database is local to the satellite machine, any changes are immediately available on the main workstation and satellite machines, and there is no reconciling disparate databases. As part of the (manual) SSHFS mount command, I make a local copy on the satellite so the password is available if my central server is not. Note, if my primary home workstation becomes unavailable, and I need to modify the database in any way, I will need to manually merge my KeePassX databases.

My previous architecture is described above. Adding a dual-boot Windows 7 installation to the mix gives me a number of challenges:

  1. There is the problem of sharing the database between both OSes (Windows 7 and Debian), such that both versions of KeePassX operate without having to redirect KeePassX to a different location (C:\Users\trey\keepass in Windows, and /home/trey/keepass in Debian).
  2. Making the database available via SSHFS will pose a challenge on the Windows side.
  3. Making backups of the database may be difficult from the Windows side

My solutions to the above:

  1. Sharing the database between the two systems is relatively straightforward. This is where Linux plays the glue system, and makes up for the inadequacies of others. Windows 7 will store the master password database here: C:\Users\trey\keepass\. I can mount the C: drive in Linux (the ntfs-3g filesystem driver is quite mature), and then bind mount the Windows directory to /home/trey/keepass/. Here are the relevant /etc/fstab entries:
    /dev/sda2                       /windows           ntfs    defaults,uid=1000 0 0
    /windows/Users/trey/keepass     /home/trey/keepass none    bind              0 0

    If I’m booted into Linux, everything is as it was. I don’t anticipate that the database actually residing on an NTFS volume to be a concern, but usage may dictate otherwise.

  2. Making the directory available from the Debian side is already done, and works as expected. Doing so from Windows is a bit more difficult. I’ll need to install OpenSSH in Cygwin, which is done, but it’s not configured. I’ll first need to expose C:\Users\trey\keepass in the Cygwin filesystem tree. I’ll also need to copy the various SSH keys into the Cygwin environment, so my satellite devices don’t know (or care) when they mount the SSHFS volume. I’m currently writing this from Debian; I’ll need to reboot into Windows and continue this post later.
  3. I have no idea how my general rsnapshot backup will work if Windows is booted. I’ll have to think of that later, but assuming the keepass directory is properly exposed in Windows/Cygwin, it should be OK.

On to the Windows side…

Adding Windows 7 to my PXE boot server…

I would have thought this would be difficult, but I found this Install Windows 7 over PXE from Linux without WAIK guide. I will document what I had to do differently (since that guide is designed for CentOS 5.3).

The first major change I needed to make was in the /etc/init.d/binl script; it called some things (e.g. /etc/sysconfig/network) which just doesn’t exist in Debian. I had to rip out all of the CentOS/Red Hat bits, and replace them with Debian ones. I also had to edit the binlsrv2.py file, since it had the tftp root path hardcoded in it.

Since tftpd-hpa was already set up (see my previous posts on the PXE boot subject), I just needed to add a remap file to /srv/tftp/windows/remap. This will cause tftpd-hpa to remap backslashes (‘\’) to slashes (‘/’). Setting up samba was pretty simple. I created the [REMINST] share as instructed, and mounted the Windows 7 x64 ISO to that share.

Importing the default boot files was straightforward, just used the wimextract tool found in the win7pxelinux.tgz distributed by the author of the ultimatedeployment.org site. I placed all of the executable files in /usr/local/bin, so I wouldn’t have to adjust my $PATH variable. I ran into an issue generating the winpe.wim Windows image (kept giving me an error that //windows/system32 couldn’t be found). To work around this problem, I added a “mkdir //windows/system32” command to the actionfile.txt, and it worked. Well, at least it didn’t give me an error.

The next step was to run a Perl script called bcdedit.pl. For this I had to install libhivex-bin, so I could run hivexsh (executed by bcdedit.pl). There was a problem, though. The hivexsh script generated a large number of errors. As far as I could figure out, hivexsh is slightly different between the Red Hat way and Debian way. In Debian, the -w option does not take an argument, whereas in Red Hat/CentOS the argument is the hive (Windows registry) file. Correcting this in bcdedit.pl was just a matter of moving the $bcd variable to the end of the command, rather than directly after the -w option.

Now was time to test it out. It looks like it launches, but it can’t seem to pull the files it needs from TFTP. It looks like it’s trying, just can’t find the files it wants:

…after some trial and error I notice that the WinPE client can’t find ‘hiberfil.sys’, a file created by Windows 7 when it hibernates. Thus the installation halts. Just touching the file isn’t enough. I can’t even make one in my Windows 7 virtual machine, since the guest firmware doesn’t support hibernation (not that it really needs to). So I’m stuck trying to figure out where I can grab that file from. I think it’s in the BCD I generated, but I don’t know where. Using the wimextract command from the toolset requires you to know where it is in the path. wimlib, which comes with an implementation of Windows’ imagex. I will have to start a new blog post for that, since I’ll have to start from scratch.