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
sshfs email@example.com:/path/to/box $ENCBOX_PATH -o uid=$(id -u) -o gid=$(id -g)
I pass the
gid parameters to map my local user to the remote one.
Otherwise I would not be able to access the data. Once
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 --extpass="keyring-query --service=encbox --user=foo" $ENCBOX_PATH $BOX_PATH
To avoid letting the box stay open indefinitely, I also set EncFS’
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 compiler1 and the inability to specify additional
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
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.
Such as XeLaTeX which I use almost exclusively these days. ↩
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)