I found the time to update my static comment script and will have the time to review comments again for the foreseeable future. Thus spam bots: ready, steady, go!

In this day and age, cloud storage is a convenient way to access data from any location. However for privacy and data theft reasons, using third party products always leaves a sour taste in my opinion. To host my own centralized and encrypted data storage for small, highly confidential data, I set up a system combining SSHFS and EncFS.

SSHFS is a FUSE file system to mount a remote file system securely through an SSH tunnel. As a nice side effect, this means that no additional client setup is required once the keys are distributed accordingly. EncFS is another FUSE file system that transparently decrypts an encrypted data source as a mounted directory. In the remaining post, I will explain how I use both systems together to read and write securely to an encrypted remote file system on my VPS.

Before mounting the file systems, we need two empty mount points: one that contains the SSHFS mounted encrypted directory (let’s call the path ENCBOX_PATH) and one that contains the decrypted data (let’s call that BOX_PATH). Before mounting the remote file system you should make sure that the remote directory actually exists. If that’s the case, you mount the remote directory with

sshfs foo@bar.com:/path/to/box $ENCBOX_PATH -o uid=$(id -u) -o gid=$(id -g)

I pass the uid and gid parameters to map my local user to the remote one. Otherwise I would not be able to access the data. Once $ENCBOX_PATH is available we can encrypt the contents with

encfs $ENCBOX_PATH $BOX_PATH

To avoid having to type in the password every time, we have to pass the password programmatically to EncFS. You could either get it from somewhere and pass it through stdin using the --stdin option or specify an external programm that prints the password on stdout. I use the latter together with my keyring-query script. It is a small Python script that uses the system’s keyring to store and retrieve arbitrary secrets. Thus before trying to mount the encrypted file system I will first store the password using

keyring-query --service=encbox --user=foo

The same command line is then used for the encfs command

encfs --extpass="keyring-query --service=encbox --user=foo" $ENCBOX_PATH $BOX_PATH

To avoid letting the box stay open indefinitely, I also set EncFS’ --idle option to five minutes.

Because all those steps are quite elaborate, I bundled this together in a small shell script. Besides the basic mounting of the file systems the script also takes care of checking error conditions and unmounting the file systems if they are already mounted.

The outlined solution is a huge relief for keeping confidential data centrally located that I don’t want to share with Google or Dropbox. However, this comes at a price: Although the bandwidth is not too bad (around 1.8 MB/s on a fast line), writing interactively (e.g. editing with Vim) becomes a pain due to the high latencies involved.

Compiling a LaTeX/BibTeX document is a tedious process does not integrate very well with the make idiom. Until now, I used rubber to compile my documents. However, there are several shortcomings that make rubber only a good rather than a perfect solution. Most notably, it is basically unmaintained for years now with the current release dating back to 2006. This wouldn’t be a big issue if it weren’t for some annoyances such as in-source specification of the LaTeX compiler¹ and the inability to specify additional flags (e.g. -shell-escape).

Thanks to Austin Clements and his a spiritual successor to rubber, latexrun, the days of frustration and despair are over now. The name might not be as sexy but the feature list and improvements are certainly impressive. Most importantly, latexrun spits out errors and warnings in a format that makes Vim’s quickfix window happy and I can finally specify commands and arguments willy-nilly from outside of my document.

(Un)fortunately, latexrun likes to output auxiliary files in a separate build directory called latex.out. While that works for most packages, it breaks with the source highlighting package minted. As a temporary workaround, one can use the -O . option to use the current working directory as the build directory. But apart from that issue, I am very happy with this little program.

When a friend found out that I am “blogging”, she assumed I would be posting personal details and share my views about this and that. Aside from my very personal configurations however, that is obviously not the case. I’d like to change that a tiny little bit by linking to a page with a list of books – see also the header bar – that I read in the past. This will not only give you a limited idea about myself but also helps me keeping track of what I read.

To keep this post a bit technical, here is the bit of code that uses Font Awesome to display the Jekyll star ratings next to some of the books (props to Lawrence Woodman about the initial idea):

module Jekyll
  class RatingStars < Liquid::Tag

    def initialize(tag_name, text, tokens)
      super
      @stars = text
    end

    def render(context)
      rating = Float(@stars)
      num_full_stars = rating.floor()
      num_half_stars = rating - num_full_stars >= 0.5 ? 1 : 0
      num_empty_stars = 5 - num_full_stars - num_half_stars

      html = String.new
      html += '<span class="rating">'

      num_full_stars.times do
        html += '<i class="fa fa-star"></i>'
      end

      num_half_stars.times do
        html += '<i class="fa fa-star-half-o"></i>'
      end

      num_empty_stars.times do
        html += '<i class="fa fa-star-o"></i>'
      end

      html += '</span>'
      html
    end
  end
end

Liquid::Template.register_tag('rating', Jekyll::RatingStars)