dim13

M:Tier Binpatches

23 June 2016

Here is my alternative setup for M:Tier binpatches. It differs slightly from offical setup.

I use /etc/pkg.conf instead of defining a $PKG_PATH variable. It looks like:

installpath = http://ftp.spline.de/pub/OpenBSD/%c/packages/%a/
installpath += https://stable.mtier.org/updates/%c/%a

The daily check is performed with /etc/daily.local instead of defining cron entry directly. It also fetches source tree updates.

#!/bin/sh

updatesrc() {
    echo "Updating Source Tree"
    echo
    VERSION=OPENBSD_$(uname -r | tr . _)
    MODULES='src ports' # you may wish to add xenocara too
    CVSROOT=anoncvs@openbsd.cs.fau.de:/cvs
    (cd /usr && cvs -qd ${CVSROOT} up -APCd -r${VERSION} ${MODULES})
    echo
}

updatepkg() {
    echo "Checking package changes"
    echo
    pkg_add -sux
    echo
}

updatesrc
updatepkg

And finaly updating itself is performed as usual with pkg_add -ui.

PS: don't forget to fetch the current siging key:

cd /etc/signify && ftp https://stable.mtier.org/mtier-59-pkg.pub

Today I finally shut down my old CVS repo. After nearly 15 years of operation, it's time to move on. Few bites, worth saving for a sake of archeology, are converted and imported into my local playground Git repo. Links are preserved, as far as possible.

CVS was some cumbersome to maintain in a chrooted environment. Related tools weren't updated for years. And since I've switched from C to Go, I've barely used it anymore.

It's time to catch up with the progress. Goodbye CVS.

Conversion process

It was quite straightforward. I've used cvs2svn with a custom options file for it.

The whole process sofar: update few bits in cvs2git.options, as described here (it boils down to committer name mapping and CVSROOT repository location). Then:

cvs2git --options=cvs2git.options
mkdir newrepo && cd newrepo
git init && cat ../newrepo-tmp/git-{blob,dump}.dat | git fast-import
git checkout && git gc
git add origin git@dim13.org:newrepo.git
git push --all origin

This way all your tags and branches stay preserved. Repeat until all your repos are converted.

Hello HTTP/2.0

31 March 2016

This site is serving HTTP/2.0 now.

www.nginx.com/blog/nginx-1-9-5/

Zero downtime with Let's Encrypt

26 November 2015

Introduction

Apparently there is no way to define an alternative port for Let's Encrypt verification process. ACME specification states explicitly that those must be 80 and 443 ports.

Thus, with production servers running, you either have to tolerate downtime or let Let's Encrypt client tamper with your precious configs. None of both is very desirable.

Opposite to the official client, lego client lets you define a custom port, you can then redirect the verification traffic to. And here is, how I done it.

/etc/pf.conf

First, lets redirect requests from special IP's to 80 and 443 to another port (8443 in my case).

table <letsencrypt> persist file "/etc/letsencrypt.pf"

pass in quick inet proto tcp from <letsencrypt> \
    to port {http, https} rdr-to egress port 8443

Please note, that we are redirecting to external IP (egress interface), since there is no way to tell lego to listen on localhost. You can only define a custom port.

/etc/letsecnrypt.pf

This file contains special URIs, where verification requests are coming from. The first two entries are important. The other two are only for completeness sake here.

outbound1.letsencrypt.org
outbound2.letsencrypt.org

acme-staging.api.letsencrypt.org
acme-v01.api.letsencrypt.org

IPs get resolved and loaded into letsencrypt table automaticly. Or load it manually

pfctl -tletsencrypt -Ta -f /etc/letsencrypt.pf

Beware: those IPs may change frequently. I suggest you to reload them periodically.

lego

And now, the client

go get -u github.com/xenolf/lego
lego -m another@example.com --port 8443 -d example.com run

And that's all.

Conclusion

This setup has several benefits.

you don't need to run verification client as root any more (unprivileged port)
your web-server is still running and serving clients
your web-server configuration remains intact, as none automatical tool corrupts it
you get your certs with zero downtime

References

github.com/letsencrypt/acme-spec/issues/33

letsencrypt.github.io/acme-spec/

github.com/xenolf/lego

Let's Encrypt psutil