Status Update November 2021

It has been a fun November! You may have noticed that this blog lost the https connectivity for a few days! As a reminder, Guix system renews certificates for domains via

sudo /var/lib/certbot/renew-certificates

The above script is called automatically, but I figured that a good start would be to manually try to run this script and see what happens. So I sshed into the server to give it a try. I got this error message:

Certbot failed to authenticate some domains (authenticator: webroot).
 The Certificate Authority reported these problems:
  Domain: mail.gnucode.me
  Type:   dns
  Detail: DNS problem: NXDOMAIN looking up A for mail.gnucode.me
   - check that a DNS record exists for this domain

  Domain: wireguard.gnucode.me
  Type:   dns
  Detail: DNS problem: NXDOMAIN looking up A for wireguard.gnucode.me
  - check that a DNS record exists for this domain

To fix it I just removed the subdomains “mail.gnucode.me”, and “wireguard.gnucode.me”, from the config file for this website.

Then re-running certbot totally worked. While we are talking about certbot. I am glad that guix has support for it. They use the python acme client, which certainly works, but I have recently discovered that the OpenBSD folks have made their own acme client. It looks like their client might be dependent on their httpd daemon, which is potentially why Guix System doesn’t use it. Anywho…

In other news, I have still been working on my opensmtpd service using guix records. I made the decision to tweak the records that I am using for my opensmtpd service. Before I had set up the configuration to follow nckx’s advice from #guix irc channel:

"...as I think Guix services ought to faithfully wrap the native syntax whenever
possible (implement alternative simple APIs on top of that — fine)."

To follow this advice, I avoided trying to develop something like this:

(service email-service-type
   (email-configuration
     (domains (list "gnucode.me" "gnu-hurd.com"))
     (use-letsencrypt #t)))

Instead I originally tried this type of service configuration, where I had several lists of records of includes, tables, pkis, etc. Other records like the filters, which may have tables, would refer to the table record via a string. This could cause issues where the user mispelled the table name.

(service opensmtpd-service
  (opensmtpd-configuration
    (includes ...)
    (tables ...)
    (pkis ...)
    (filters ...)
    (listen-on ...)
    (actions ...)
    (matches ...)))

I also thought of other annoyances. Why would have a list of actions, and then have the match record have a fieldname action that accepts a string of the action name. It would be more robust if instead it accepted an <opensmtpd-action-configuration> record. Well when you start to think like this, the resulting example config may turn into:

(service opensmtpd-service-type
         (opensmtpd-configuration
          (listen-ons
           (list (opensmtpd-listen-on
                  (interface "eth0")
                  (filter
                   (opensmtpd-filter-chain-configuration
                    (list
                     (opensmtpd-filter-phase ...)
                     (opensmtpd-filter-phase ...))))
                  (hostnames (opensmtpd-table-configuration
                              (values "gnucode.me" "gnu-hurd.com")))
                  (ca
                   (opensmtpd-ca-configuration ...))
                  (pkis
                   (list
                    (opensmtpd-pki-configuration ...)
                    (opensmtpd-pki-configuration ...))))))
          (matches
           (list
            (opensmtpd-match
             (options
              (list
               (opensmtpd-match-options-configuration
                (table
                 (opensmtpd-table ...)))
               (opensmtpd-match-options-configuration ...)))
             (action
              (opensmtpd-action
               (opensmtpd-local-delivery-configuration
                (method
                 (opensmtpd-maildir-configuration ...))
                (alias (opensmtpd-table ...))))))))))

I believe this change will fix various mispelling errors and should make the service more robust.

Tweaking the datastructure has helped me to find other things that could be simpler. One example is the <opensmtpd-action> record. I used to have the datastructure be the <opensmtpd-action>, which included a fieldname that has as its value either a <opensmtpd-local-delivery-configuration> or a <opensmtpd-relay-configuration> like this:

                              <opensmtpd-action>
                              opensmtpd-action-name
                              opensmtpd-action-method
                                       |
                                      / \
                                     /   \
                                    /     \
                                   /       \
                                  /         \
<opensmtpd-local-delivery-configuration>   <opensmtpd-relay-configuration>

It is actually simpler to delete the <opensmtpd-action> record, and replace it with two records: <opensmtpd-local-delivery-action> and <opensmtpd-relay-configuration-action>

Of course when you tweak datastructures, then you have to deal with tweaking the code to work with the new datastructures. That is interesting. Most of the TODO items I have for this project are in my opensmtpd.org file.

Thanks for reading!