At the end of January 2016 Let's Encrypt fixed the last bug which prevented letsencrypt-remote from authenticating via DNS.
It is now possible to generate TLS certificates for private servers if you can delegate name resolution via your DNS provider.
Let's say you want to generate a certificate for use on your Laptop.
You first need to create a subdomain pointing to 127.0.0.1.
Something like this in your zone for localhost.example.com:
localhost IN A 127.0.0.1
Additionally you need to delegate _acme-challenge.localhost.example.com to an IP which is reachable by the Let's Encrypt servers and where you can access DNS port 53.
For example your web server if you have one:
_acme-challenge.localhost IN NS www
If you use your web server, you could use ssh to forward the port 8053 to your laptop:
$ ssh email@example.com -R 8053:localhost:8053
You then need to use something to forward remote UDP packets from port 53 of the server to the forwarded TCP port 8053,
for example socat:
# socat -T15 udp4-recvfrom:53,reuseaddr,fork tcp:localhost:8053
Now on your laptop you can use letsencrypt-remote to create a certificate using DNS:
% letsencrypt-remote --dns localhost.example.com
If everything worked correctly:
- letsencrypt-remote should have started a DNS server
- requested certificate signing
- the Let's Encrypt servers should be delegated to your server for the DNS query
- the request be forwarded to your laptop
- the answer sent back
- and you got a signed certificate for localhost.example.com
This also works for other private ip ranges like 10.0.0.0/8 or 192.168.1.0/24.
After several years and multiple attempts, I finally have a website again.
I tried quite a few static website generators, including starting my own, until I finally settled with the recently announced Lektor.
The main addition to Lektor is my reStructuredText plugin lektor-rst.
I had all the old content in rst already and I favour it over markdown.
The source code for my website is available on GitHub at https://github.com/fschulze/florian-schulze.
I recently ran into the issue that our Hudson installation didn't report
test failures. After digging for a bit, I discovered, that scripts
installed by zc.recipe.egg don't return the exit code for some cases.
There is a bugreport at
https://bugs.launchpad.net/zc.buildout/+bug/164629. In our case the
generated coverage script depended on this and because the sys.exit was
missing, the test failures were masked.
The following is a way to fix this in your buildouts now until it's
fixed in zc.buildout:
extensions = buildout.extensionscripts
The patchScriptGeneration function in src/buildout-utils.py
looks like this:
from zc.buildout import easy_install
if not 'sys.exit(' in easy_install.script_template:
easy_install.script_template = easy_install.script_template.replace(
The last releases of mr.developer (1.2 and 1.3) reduce the amount of
The packages from auto-checkout are now automatically added and removed
from the list of development packages when you switch buildout
configurations. Before you had to run develop reset and rerun
buildout for that to work. If you have an existing checkout, you may
want to reset it, so that this change is picked up.
The last used buildout configuration is now read directly. That means if
you change source declarations in your buildout configuration, then you
don't have to rerun buildout anymore for mr.developer to pick up those
changes. You still have to run buildout after changing the develop
status of a package, but that's the same as with a plain buildout
Since I started to tame the snakepit, I made many improvements to
make it even less scary.
The python buildout now auto detects the platform you are on, so it
works for many more systems then just Mac OS X without a custom
configuration. On Mac OS X it automatically detects whether you are on
Leopard or Snow Leopard. Since today it also works on Snow Leopard with