M:Tier Binpatches

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.


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

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


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
By Dimitri Sokolyuk

Goodbye CVS

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.

By Dimitri Sokolyuk

Hello HTTP/2.0

This site is serving HTTP/2.0 now.

By Dimitri Sokolyuk

Zero downtime with Let's Encrypt


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.


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.


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.



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.


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.


This setup has several benefits.


Similar solution for Linux

iptables --table nat --append PREROUTING --protocol tcp \
    --source <Validation Authority IP address> --dport 443 \
    --jump REDIRECT --to-ports <ACME client port>
By Dimitri Sokolyuk

Let's Encrypt psutil

Good news! 'psutil' is supported on OpenBSD now. However I still mislike official client. It's bloated for no reason.

By Dimitri Sokolyuk

See the index for more articles.