While I'm not convinced that encrypting everything by default is
necessarily a good idea, it is certainly true that encryption has its
uses. Unfortunately, for the longest time getting an SSL certificate
from a CA was quite a hassle -- and then I'm not even mentioning the
fact that it would cost money, too. In that light, the letsencrypt
project is a useful alternative: rather than having to dabble with
emails or webforms, letsencrypt does everything by way of a few scripts.
Also, the letsencrypt CA is free to use, in contrast to many other
certificate authorities.
Of course, once you start scripting, it's easy to overdo it. When you go
to the letsencrypt website and try to install their stuff, they point
you to a "letsencrypt-auto" thing, which starts installing a python
virtualenv and loads of other crap, just so we can talk to a server
and get a certificate properly signed. I'm sure that makes sense for
some people, and I'm also sure it makes some things significantly
easier, but honestly, I think it's a bit overkill. Luckily, there is
also a regular
letsencrypt script that doesn't do all the
virtualenv
stuff, and which is
already packaged for
Debian, so
installing that gets us rid of the overkill bits. It's not in stable,
but it
is an arch:all package. Unfortunately, not all dependencies are
available in Jessie, but backporting it turned out to be not too complicated.
Once the client is installed, you need to get it to obtain a
certificate, and you need to have the certificate be activated for your
webserver. By default, the letsencrypt client will update your server
configuration for you, and run a temporary webserver, and do a whole lot
of other things that I would rather not see it do. The good news,
though, is that you can switch all that off. If you're willing to let it
write a few files to your DocumentRoot, it can do the whole thing
without any change to your system:
letsencrypt certonly -m <your mailaddress> --accept-tos --webroot -w \
/path/to/DocumentRoot -d example.com -d www.example.com
In that command, the
-m option (with mail address) and the
--accept-tos option are only required the first time you ever run
letsencrypt. Doing so creates an account for you at letsencrypt.org,
without which you cannot get any certificates. The
--accept-tos
option specifies that you accept
their terms of
service, which you might want to
read first before blindly accepting.
If all goes well,
letsencrypt will tell you that it wrote your account
information and some certificates somewhere under
/etc/letsencrypt.
All that's left is to update your webserver configuration so that the
certificates are actually used. No, I won't tell you how that's done --
if you need that information, it's probably better if you just use the
apache or nginx plugin of
letsencrypt, which updates your webserver's
configuration automatically. But if you already know how to do so, and
prefer to maintain your configuration by yourself, then it's good to
know that it is at least possible.
Since we specified two
-d parameters, the certificate you get from the
letsencrypt CA will have subjectAlternativeName fields, allowing you to
use them for more than one domain name. I specified
example.com
and
www.example.com as the valid names, but there is nothing in
letsencrypt requiring that the domain names you specify share a
suffix; so yes, it is certainly possible to have multiple domains on a
single certificate, if you want that.
Finally, you need to ensure that your certificates are renewed before
they expire. The easiest way to do that is to add a cronjob, which runs
letsencrypt again; only this time, you'll need slightly different
options:
letsencrypt certonly --renew-by-default --webroot -w \
/path/to/DocumentRoot -d domain.name.tld -d www.domain.name.tld
The
--renew-by-default option tells
letsencrypt that you want to
renew your certificates, not create new ones. If you specify this, the
old certificate will be revoked, and a new one will be generated, again
with three months validity. The symlinks under
/etc/letsencrypt/live
will be updated, so if your webserver's configuration uses those as the
path to your certificates, you don't need to update any configuration
files (although you may need to restart your webserver). You'll also
notice that the
-m and
--accept-tos options are not specified this
time around; this is because those are only required when you want to
create an account -- once that step has been taken,
letsencrypt will
read the necessary information from its configuration files (and
creating a new account for every renewal is just silly).
With that, you now have a working, browser-trusted, certificate.
Update: fix mistake about installing on Jessie. It's possible (I've
done so), but it's been a while and I forgot that I had to recompile
several of
letsencrypt's dependencies in order for it to be
installable.
After an usually long hiatus, the 
The phone company logs provide a register of locations to check out
when one want to figure out what the tracked person was doing. It is
unavailable for most of us, but provided to selected government
officials, company staff, those illegally buying information from
unfaithful servants and crackers stealing the information. But the
public information can be collected and analysed, and a free software
tool to do so is called
Version 6 of git-annex, released last week, adds a major new feature;
support for unlocked large files that can be edited as usual and committed
using regular git commands.
For example:
While the details about how to join the set of paid contributors have always been public (
Since moving to Japan, I got more and more interested in history, especially the recent history of the 20th century. The book I just finished, Ian Buruma (
The comparison of Germany and Japan with respect to their recent history as laid out in Buruma s book throws a spotlight on various aspects of the psychology of German and Japanese population, while at the same time not falling into the easy trap of explaining everything with difference in the guilt culture. A book of great depth and broad insights everyone having even the slightest interest in these topics should read.
I am happy to share here a project I was a part of during last year, that ended up being a complete success and now stands to be repeated: The diploma course on embedded Linux, taught at 
Back in November, we 
Those of you not interested in boring and melancholic look-back onto history can safely skip reading this one. For those a bit interested in the history of TeX in Debian, please read on.
Debian releases and TeX systems
The TeX system of choice has been for long years 
Development over the years
TeX Live 2005 was just another TeX system but not the preferred one in Debian Etch and beyond. But then in May 2006, Thomas Esser announced the end of development of teTeX, which cleared the path for TeX Live as main TeX system in Debian (and the world!). The next release of Debian, Lenny (1/2009), already carried only TeX Live. Unfortunately it was only TeX Live 2007 and not 2008, mostly due to me having been involved in rewriting the upstream infrastructure based on Debian package files instead of the notorious xml files. This took quite a lot of attention and time from Debian away to upstream development, but this will be discussed in a different post.
Similarly, the release of TeX Live included in Debian Squeeze (released 2/2011) was only TeX Live 2009 (instead of 2010), but since then (Wheezy and Jessie) the releases of TeX Live in Debian were always the latest released ones.
Current status
Since about 2013 I am trying to keep a regular schedule of new TeX Live packages every month. These helps me to keep up with the changes in upstream packaging and reduces the load of packaging a new release of TeX Live. It also bring to users of unstable and testing a very up-to-date TeX system, where packages at most lack 1 month of behind the TeX Live net updates.
Future
As most of the readers here know, besides caring for TeX (Live) and related packages in Debian, I am also responsible for the TeX Live Manager (tlmgr) and most of upstream s infrastructure including network distribution. Thus, my (spare, outside work) time needs to be distributed between all these projects (and some others) which leaves less and less time for Debian packaging. Fortunately the packaging is in a state that making regular updates once a month is less of a burden, since most steps are automatized. What is still a bit of a struggle is adapting the binary package (
