Ryan Kavanagh's /dev/brain

Battery charge start and stop threshold on OpenBSD

Wed, 20 Dec 2023 11:11:59 -0500

I often use my laptops as portable desktops: they are plugged into AC power and an external monitor/keyboard 95% of time. Unfortunately, continuous charging is hard on the battery. To mitigate this, ThinkPads have customizable start and stop charging thresholds, such that the battery will only start charging if its level falls below the start threshold, and it will stop charging as soon as it reaches the stop threshold. Suggested thresholds from Lenovo’s battery team can be found in this comment.

You can set these thresholds on Linux using tlp-stat(8), and you can make the values persist across reboots by setting START_CHARGE_THRESH_BAT0 and STOP_CHARGE_THERSH_BAT0 in /etc/tlp.conf.

I recently installed OpenBSD on my work ThinkPad, but struggled to find any information on how to set the thresholds under OpenBSD. After only finding a dead-end thread from 2021 on misc@, I started digging around on how to implement it myself. The acpithinkpad and acpibat drivers looked promising, and a bit of Google-fu lead me to the following small announcement in the OpenBSD 7.4 release notes:

New sysctl(2) nodes for battery management, hw.battery.charge*. Support them with acpithinkpad(4) and aplsmc(4).

Lo and behold, setting the start and stop threshold in OpenBSD is simply a matter of setting hw.battery.chargestart and hw.battery.chargestop with sysctl. The documentation was not committed in time for the 7.4 release, but you can read it in -CURRENT’s sysctl(2). I personally set the following values in /etc/sysctl.conf:

hw.battery.chargestart=40
hw.battery.chargestop=60

Routable network addresses with OpenIKED and systemd-networkd

Sat, 25 Jun 2022 07:41:37 -0400

I’ve been using OpenIKED for some time now to configure my VPN. One of its features is that it can dynamically assign addresses on the internal network to clients, and clients can assign these addresses and routes to interfaces. However, these interfaces must exist before iked can start. Some months ago I switched my Debian laptop’s configuration from the traditional ifupdown to systemd-networkd. It took me some time to figure out how to have systemd-networkd create dummy interfaces on which iked can install addresses, but also not interfere with iked by trying to manage these interfaces. Here is my working configuration.

First, I have systemd create the interface dummy1 by creating a systemd.netdev(5) configuration file at /etc/systemd/network/20-dummy1.netdev:

[NetDev]
Name=dummy1
Kind=dummy

Then I tell systemd not to manage this interface by creating a systemd.network(5) configuration file at /etc/systemd/network/20-dummy1.network:

[Match]
Name=dummy1
Unmanaged=yes

Restarting systemd-networkd causes these interfaces to get created, and we can then check their status using networkctl(8):

$ systemctl restart systemd-networkd.service
$ networkctl
IDX LINK     TYPE     OPERATIONAL SETUP
  1 lo       loopback carrier     unmanaged
  2 enp2s0f0 ether    off         unmanaged
  3 enp5s0   ether    off         unmanaged
  4 dummy1   ether    degraded    configuring
  5 dummy3   ether    degraded    configuring
  6 sit0     sit      off         unmanaged
  8 wlp3s0   wlan     routable    configured
  9 he-ipv6  sit      routable    configured

8 links listed.

Finally, I configure my flows in /etc/iked.conf, making sure to assign the received address to the interface dummy1.

ikev2 'hades' active esp \
        from dynamic to 10.0.1.0/24 \
        peer hades.rak.ac \
        srcid '/CN=asteria.rak.ac' \
        dstid '/CN=hades.rak.ac' \
        request address 10.0.1.103 \
        iface dummy1

Restarting openiked and checking the status of the interface reveals that it has been assigned an address on the internal network and that it is routable:

$ systemctl restart openiked.service
$ networkctl status dummy1
● 4: dummy1
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /etc/systemd/network/20-dummy1.network
                          Type: ether
                          Kind: dummy
                         State: routable (configured)
                  Online state: online
                        Driver: dummy
              Hardware Address: 22:50:5f:98:a1:a9
                           MTU: 1500
                         QDisc: noqueue
  IPv6 Address Generation Mode: eui64
          Queue Length (Tx/Rx): 1/1
                       Address: 10.0.1.103
                                fe80::2050:5fff:fe98:a1a9
                           DNS: 10.0.1.1
                 Route Domains: .
             Activation Policy: up
           Required For Online: yes
             DHCP6 Client DUID: DUID-EN/Vendor:0000ab11aafa4f02d6ac68d40000

I’d be happy to hear if there are simpler or more idiomatic ways to configure this under systemd.

Writing BASIC-8 on the TSS/8

Wed, 07 Apr 2021 20:08:52 -0400

I recently discovered SDF’s PiDP-8. You can access it over SSH and watch the blinkenlights over its twitch stream. It runs TSS/8, a time-sharing operating system written in 1967 by Adrian van de Goor while a grad student here at CMU. I’ve been having fun tinkering with it, and I just wrote my first BASIC program¹ since high school. It plots the graph of some user-specified univariate function. I don’t claim that it’s elegant or well-engineered, but it works!

10  DEF FNC(X) = 19 * COS(X/2)
20  FOR Y = 20 TO -20 STEP -1
30     FOR X = -25 TO 24
40     LET V = FNC(X)
50     GOSUB 90
60  NEXT X
70  PRINT ""
80  NEXT Y
85  STOP
90  REM SUBROUTINE PRINTS AXES AND PLOT
100 IF X = 0 THEN 150
110 IF Y = 0 THEN 150
120 REM X != 0 AND Y != 0 SO IN QUADRANT
130 GOSUB 290
140 RETURN
150 GOSUB 170
160 RETURN
170 REM SUBROUTINE PRINTS AXES (X = 0 OR Y = 0)
180 IF X + Y = 0 THEN 230
190 IF X = 0 THEN 250
200 IF Y = 0 THEN 270
210 PRINT "AXES INVARIANT VIOLATED"
220 STOP
230 PRINT "+";
240 GOTO 280
250 PRINT "I";
260 GOTO 280
270 PRINT "-";
280 RETURN
290 REM SUBROUTINE PRINTS FUNCTION GRAPH (X != 0 AND Y != 0)
300 IF 0 <= Y THEN 350
310 REM Y < 0
320 IF V <= Y THEN 410
330 REM Y < 0 AND Y < V SO OUTSIDE OF PLOT AREA
340 GOTO 390
350 REM 0 <= Y
360 IF Y <= V THEN 410
370 REM 0 <= Y  AND V < Y SO OUTSIDE OF PLOT AREA
380 GOTO 390
390 PRINT " ";
400 RETURN
410 PRINT "*";
420 RETURN
430 REM COPYRIGHT 2021 RYAN KAVANAGH RAK AT RAK.AC
440 END

It produces the following output:

                         I
                         I
*           **           I           **
*           **           I           **
**          **          *I*          **          *
**          **          *I*          **          *
**         ***          *I*          ***         *
**         ****         *I*         ****         *
**         ****         *I*         ****         *
**         ****         *I*         ****         *
**         ****        **I**        ****         *
***        ****        **I**        ****        **
***        ****        **I**        ****        **
***        ****        **I**        ****        **
***       *****        **I**        *****       **
***       ******       **I**       ******       **
***       ******       **I**       ******       **
***       ******       **I**       ******       **
***       ******       **I**       ******       **
***       ******      ***I***      ******       **
-------------------------+------------------------
    ******      ******   I   ******      ******
    ******      ******   I   ******      ******
    *****       ******   I   ******       *****
    *****       ******   I   ******       *****
    *****        *****   I   *****        *****
    *****        *****   I   *****        *****
    *****        *****   I   *****        *****
    *****        ****    I    ****        *****
    *****        ****    I    ****        *****
     ****        ****    I    ****        ****
     ****        ****    I    ****        ****
     ***         ****    I    ****         ***
     ***          ***    I    ***          ***
     ***          ***    I    ***          ***
     ***          ***    I    ***          ***
      **          **     I     **          **
      **          **     I     **          **
      *            *     I     *            *
                         I
                         I

Next up, I am going to try my hand at writing some FORTRAN or some FOCAL69. If you like tinkering with old systems, then you should give the TSS/8 a try.

It’s written in the BASIC-8 dialect. ↩︎

Static Comments in Hugo

Fri, 12 Mar 2021 13:32:34 -0500

I switched from Jekyll to Hugo last week for a variety of reasons. One thing that was missing was a port of the “jekyll-static-comments” plugin that I used to use. I liked it because it saved readers from being tracked by Disqus or other comments solutions, and it required no javascript.

To comment, users would email me their comment following a template attached to the bottom of each post. I then piped their email through a script to add it to the right post. As an added benefit, I could delegate comment spam detection to my mail server.

I’ve managed to reimplement this setup using Hugo. For those who are interested in a similar setup, here is what you need to do.

Pages with comments

Instead of being single files, pages need to be leaf bundles. For example, this means that your blog post must be located at /content/blog/2021-03-12-static-comments-in-hugo/index.md instead of /content/blog/2021-03-12-static-comments-in-hugo.md. This lets you store the comments as page resources in the subdirectory /content/blog/2021-03-12-static-comments-in-hugo/comments/.

Partials

You should create a comments.html partial and include it in the layout for the pages which should get comments:

<div class="post-comments">
  <p class="comment-notice"><b>Comments</b>: To comment on this post,
	send me an email following the template below. Your email address
	will not be posted, unless you choose to include it in
	the <span style="font-family: monospace;">link:</span> field.</p>
  <pre class="comment-notice">
To: Your Name &lt;your.email<span>@</span>example.org&gt;
Subject: [blog-comment] {{ .Page.RelPermalink }}

post_id: {{ .Page.RelPermalink }}
author: [How should you be identified? Usually your name or "Anonymous"]
link: [optional link to your website]

Your comments here. Markdown syntax accepted.</pre>

  {{ $scratch := newScratch }}
  {{ $scratch.Set "comments" (.Resources.Match "comments/*yml") }}
  {{ if eq 1 (len ($scratch.Get "comments")) }}
  <h2>1 Comment</h2>
  {{ else }}
  <h2>{{ len ($scratch.Get "comments") }} Comments</h2>
  {{ end }}
  {{ range ($scratch.Get "comments") }}
  <div class="post-comment {% cycle 'odd', 'even' %}">
	{{ $comment := (.Content | transform.Unmarshal) }}
	<span class="post-meta">
		{{- $comment.date | dateFormat "Jan 2, 2006 at 15:04" -}}
	</span>
	<h3 class="comment-header">
	  {{ if $comment.link }}
	  <a href="{{ $comment.link }}">{{ $comment.author }}</a>
	  {{ else }}
	  {{ $comment.author }}
	  {{ end }}
	  <br />
	</h3>
	{{ $comment.comment | markdownify }}
  </div>
  {{ end }}
</div>

Comments

To associate comments received by email to posts, I pipe them from mutt (using the | keybinding) to the following (admittedly janky) shell script. It takes the comment, reformats it appropriately, and puts it in the post’s comments subdirectory. Note that it determines which filename to use based on the email’s contents, so make sure to check that the email doesn’t contain anything nefarious before you pipe it into the script!

#!/bin/sh
# Copyright (C) 2016-2021 Ryan Kavanagh <rak@rak.ac>
# Distributed under the ISC license

BLOG_BASE="/media/t/work/blog"

MESSAGE=$(cat)

EMAIL=$(echo "${MESSAGE}" | grep "From:" | sed -e 's/From[^<]*<\?\([^>]*\)>\?.*/\1/g;s/@/-at-/g')
DATE=$(echo "${MESSAGE}" | grep "Date:" | sed -e 's/Date:\s*//g' | xargs -0 date -Iseconds -u -d)
POST_ID=$(echo "${MESSAGE}" | grep "post_id:" | sed -e 's/post_id: //g')

COMMENTS_DIR="${BLOG_BASE}/content/${POST_ID}/comments/"
COMMENT_FILE="${COMMENTS_DIR}/${DATE}_${EMAIL}.yml"

# Strip out the email headers and whitespace until the start of the comment
COMMENT_WHOLE=$(echo "${MESSAGE}" | sed -e '/^\s*$/,$!d;/^[^\s]/,$!d')
# Indent everything after the comment header
COMMENT_INDENTED=$(echo "${COMMENT_WHOLE}" | sed -e '/^\s*$/,${s/.*/  &/g}')
# And add the comment header
COMMENT_PREFIXED=$(echo "${COMMENT_INDENTED}" | sed -e '0,/^\s*$/{s/^\s*$/comment: |/}')

[ -d "${COMMENTS_DIR}" ] || mkdir -p "${COMMENTS_DIR}"

echo "Saving the comment to ${COMMENT_FILE}"

echo "date: ${DATE}" | tee "${COMMENT_FILE}"
echo "${COMMENT_PREFIXED}" | tee -a "${COMMENT_FILE}"

For example, the following comment in an email body:

post_id: /blog/2021-03-12-static-comments-in-hugo/
author: Ryan Kavanagh
link: https://rak.ac/

Dear self,

Here is a test comment for your blog post.
It supports *markdown* **syntax** and `stuff`.

Best,
Yourself

results in a file content/blog/2021-03-12-static-comments-in-hugo/comments/2021-03-12T18:47:25+00:00_rak-at-example.org.yml containing:

date: 2021-03-12T18:47:25+00:00
post_id: /blog/2021-03-12-static-comments-in-hugo/
author: Ryan Kavanagh
link: https://rak.ac/
comment: |
  Dear self,

  Here is a test comment for your blog post.
  It supports *markdown* **syntax** and `stuff`.

  Best,
  Yourself

You can see the rendered output at the bottom of this page.

Configuring OpenIKED VPNs for StrongSwan Clients

Sat, 12 Sep 2020 17:42:00 -0400

A few weeks ago I configured a road warrior VPN setup. The remote end is on a VPS running OpenBSD and OpenIKED, the VPN is an IKEv2 VPN using x509 authentication, and the local end is StrongSwan. I also configured an IKEv2 VPN between my VPSs. Here are the notes for how to do so.

In all cases, to use x509 authentication, you will need to generate a bunch of certificates and keys:

a CA certificate
a key/certificate pair for each client

Fortunately, OpenIKED provides the ikectl utility to help you do so. Before going any further, you might find it useful to edit /etc/ssl/ikeca.cnf to set some reasonable defaults for your certificates.

Begin by creating and installing a CA certificate:

# ikectl ca vpn create
# ikectl ca vpn install

For simplicity, I am going to assume that the you are managing your CA on the same host as one of the hosts that you want to configure for the VPN. If not, see the bit about exporting certificates at the beginning of the section on persistent host-host VPNs.

Create and install a key/certificate pair for your server. Suppose for example your first server is called server1.example.org:

# ikectl ca vpn certificate server1.example.org create
# ikectl ca vpn certificate server1.example.org install

Persistent host-host VPNs

For each other server that you want to use, you need to also create a key/certificate pair on the same host as the CA certificate, and then copy them over to the other server. Assuming the other server is called server2.example.org:

# ikectl ca vpn certificate server2.example.org create
# ikectl ca vpn certificate server2.example.org export

This last command will produce a tarball server2.example.org.tgz. Copy it over to server2.example.org and install it:

# tar -C /etc/iked -xzpvf server2.example.org.tgz

Next, it is time to configure iked. To do so, you will need to find some information about the certificates you just generated. On the host with the CA, run

$ cat /etc/ssl/vpn/index.txt
V       210825142056Z           01      unknown /C=US/ST=Pennsylvania/L=Pittsburgh/CN=server1.example.org/emailAddress=rak@example.org
V       210825142208Z           02      unknown /C=US/ST=Pennsylvania/L=Pittsburgh/CN=server2.example.org/emailAddress=rak@example.org

Pick one of the two hosts to play the “active” role (in this case, server1.example.org). Using the information you gleaned from index.txt, add the following to /etc/iked.conf, filling in the srcid and dstid fields appropriately.

ikev2 'server1_server2_active' active esp from server1.example.org to server2.example.org \
	local server1.example.org peer server2.example.org \
	srcid '/C=US/ST=Pennsylvania/L=Pittsburgh/CN=server1.example.org/emailAddress=rak@example.org' \
	dstid '/C=US/ST=Pennsylvania/L=Pittsburgh/CN=server2.example.org/emailAddress=rak@example.org'

On the other host, add the following to /etc/iked.conf

ikev2 'server2_server1_passive' passive esp from server2.example.org to server1.example.org \
	local server2.example.org peer server1.example.org \
	srcid '/C=US/ST=Pennsylvania/L=Pittsburgh/CN=server2.example.org/emailAddress=rak@example.org' \
	dstid '/C=US/ST=Pennsylvania/L=Pittsburgh/CN=server1.example.org/emailAddress=rak@example.org'

Note that the names 'server1_server2_active' and 'server2_server1_passive' in the two stanzas do not matter and can be omitted. Reload iked on both hosts:

# ikectl reload

If everything worked out, you should see the negotiated security associations (SAs) in the output of

# ikectl show sa

On OpenBSD, you should also see some output on success or errors in the file /var/log/daemon.

For a road warrior

Add the following to /etc/iked.conf on the remote end:

ikev2 'responder_x509' passive esp \
	from 0.0.0.0/0 to 10.0.1.0/24 \
	local server1.example.org peer any \
	srcid server1.example.org \
	config address 10.0.1.0/24 \
	config name-server 10.0.1.1 \
	tag "ROADW"

Configure or omit the address range and the name-server configurations to suit your needs. See iked.conf(5) for details. Reload iked:

# ikectl reload

If you are on OpenBSD and want the remote end to have an IP address, add the following to /etc/hostname.vether0, again configuring the address to suit your needs:

inet 10.0.1.1 255.255.255.0

Put the interface up:

# ifconfig vether0 up

Now create a client certificate for authentication. In my case, my road-warrior client was client.example.org:

# ikectl ca vpn certificate client.example.org create
# ikectl ca vpn certificate client.example.org export

Copy client.example.org.tgz to client and run

# tar -C /etc/ipsec.d/ -xzf client.example.org.tgz -- \
	./private/client.example.org.key \
	./certs/client.example.org.crt ./ca/ca.crt

Install StrongSwan and add the following to /etc/ipsec.conf, configuring appropriately:

ca example.org
  cacert=ca.crt
  auto=add

conn server1
  keyexchange=ikev2
  right=server1.example.org
  rightid=%server1.example.org
  rightsubnet=0.0.0.0/0
  rightauth=pubkey
  leftsourceip=%config
  leftauth=pubkey
  leftcert=client.example.org.crt
  auto=route

Add the following to /etc/ipsec.secrets:

# space is important
server1.example.org : RSA client.example.org.key

Restart StrongSwan, put the connection up, and check its status:

# ipsec restart
# ipsec up server1
# ipsec status

That should be it.

Sources:

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2ClientConfig
https://www.openbsd.org/faq/faq17.html
ikectl(8)
iked.conf(5)

Specifying a custom MTA path in caff

Sat, 16 Apr 2016 12:19:53 +0000

I recently had to sign someone’s GPG key. I’ve long used the caff tool from the signing-party package to help me with this. Unfortunately, I’m using a new laptop and hadn’t yet configured caff on it. Moreover, caff uses the system MTA by default, normally found at /usr/sbin/sendmail, and I hadn’t yet properly configured it to send mail to the outside world. Since I have multiple email accounts and use mutt as my mail client, I use msmtp as my SMTP client / sendmail drop-in. This post describes how to configure caff to use msmtp.

Reading the caff man page, one sees the following tantalising hint, which leads you to believe it’s completely trivial to specify your own MTA:

$CONFIG{'mailer-send'} = [ 'sendmail', '-f', $CONFIG{'email'}, '-it' ];

Unfortunately, substituting in a custom path, e.g., /home/rak/bin/msmtp/msmtp-default, for sendmail in the above line results in a long sequence of errors when caff tries to mail the signed keys:

Bareword "home" not allowed while "strict subs" in use at (eval 218) line 1.
Bareword "rak" not allowed while "strict subs" in use at (eval 218) line 1.
Bareword "bin" not allowed while "strict subs" in use at (eval 218) line 1.
Bareword "msmtp" not allowed while "strict subs" in use at (eval 218) line 1.
Bareword "msmtp" not allowed while "strict subs" in use at (eval 218) line 1.
Bareword "default" not allowed while "strict subs" in use at (eval 218) line 1.

Fortunately, it’s still straightforward to accomplish after reading the perldoc for Mail::Mailer. In my case, it was sufficient to add the following to my ~/.caffrc:

$ENV{'PERL_MAILERS'} = 'sendmail:'.$ENV{'HOME'}.'/bin/msmtp/msmtp-default';
$CONFIG{'mailer-send'} = [ 'sendmail' ];

To specify alternate paths to your sendmail-style MTA, simply modify the value of $ENV{'PERL_MAILERS'} after the initial sendmail: bit. If you’re using stock msmtp, I believe the following pair of lines will work, though I haven’t tested it:

$ENV{'PERL_MAILERS'} = 'sendmail:/usr/bin/msmtp';
$CONFIG{'mailer-send'} = [ 'sendmail' ];

If there’s a more elegant way to accomplish this, I’d be happy to hear about it!

mutt-fetchbug: fetch BTS bug reports from mutt

Thu, 05 Jan 2012 15:58:00 +0000

I’ve been a longtime mutt user, but have gotten somewhat annoyed of having to open a new terminal when I want to read or reply to a Debian bug with mutt (using ‘bts show 123456’). How nice it would be to be able to fetch a bug report from within mutt! And so, ladies and gentlemen, I present to you mutt-fetchbug. It’s extensively based on Zack’s mutt-notmuch script (a nice interface between mutt and notmuch for searching mail, I highly recommend it).

By adding a line like the following to your ~/.muttrc, you can simply press “F7” and enter a bug number from your mutt index in order to fetch and display a bug report’s mbox file:

macro index <F7> \
    "<enter-command>unset wait_key<enter><shell-escape>~/bin/mutt-fetchbug --prompt search<enter><change-folder-readonly>~/.cache/mutt_btsresults<enter><enter-command>set wait_key<enter>" \
    "fetch bug(s) (using bts show)"

The above presupposes you’ve downloaded mutt-fetchbug and placed it with executable permissions in ~/bin.

Those interested in making improvements or extending mutt-fetchbug are more than welcome to do so, it’s licensed under the GPLv3+. It can be fetched from my git branch.

Update: Fixed the broken link to mutt-fetchbug, thanks Christian for the heads up.