One of the wishes that I and other people frequently have for ZFSis the ability to take an existing directory (and everythingunderneath it) in a ZFS filesystem and turn it into a sub-filesystemof its own. One reason for wanting this is that a number of thingsare set and controlled on a per-filesystem basis in ZFS, insteadof on a per-directory basis; if you have a (sub)directory where youwant any special value for those, you need to make it a filesystem

Recently, for reasons beyond the scope of this entry, I've beenmostly handling my email in GNU Emacs, with MH-E . GNU Emacs is famously flexible andcustomizable, mostly through the somewhat challenging method of'merely' writing the relevant (Emacs) Lisp code to do what you want.I'm capable of writing Emacs Lisp, so armed with a hammer and usinga new mail client, I have been finding plenty of things to use thathammer on ( sometimes with hackery and Emacs crimes

Recently, I discovered that 'promtool check config' doesn't alwaysfail if you have Prometheus configuration errors (which may be abug). Fortunately this was only a mild issue because quite sometime ago I added an alert for a sticky configuration reload failure.When this alert fired soon after I thought my configuration wasgood and my reload had succeeded, it was pretty straightforward towork out that 'promtool check config' was more or less lying to me(especially since the Prometheus server did log information about

Increasingly, you have to sign your outgoing email messages withDKIM . When you use DKIM to signthings, in one sense you're signing an abstract 'email message',and in another, more concrete sense, you're signing the email bodyplus some of the email message headers. You might innocently thinkthat the message headers to sign are standardized and obvious, butI've recently learned that neither is the case due to a recentdiscussion on the Exim mailing list. Different mail systems maysign

One of the lesser used aspects of TLS is thatTLS clients can send a certificate to the TLS server, in additionto the server sending one to clients. In private deployments, theseclient certificates are often issued out of a private CertificateAuthority, possibly with custom fields that are understood by thesoftware involved. However, you can also use conventional publicTLS certificates for hosts as client certificates, and there aresituations where you might want to do this; for a non-hypotheticalexample, you might want to verify

In a recent entry I noted dup() somewhat weirdseeming behavior that the new file descriptor you get from dup()(and also from dup2(), its sometimes better sibling) shares thefile's IO offset with the original file descriptor. This behavioris different from open()'ing the same file again, where you get afile descriptor with an independent file IO offset (sometimes calledthe seek offset or the seek position). In discussing this on theFediverse, I wondered if

These days, we do NAT for our internal networks on our perimeterfirewall instead of the firewalls for these internal networks . One of the advantages of doing your NAT onyour perimeter firewall is that the external NAT IP ranges you usecan be on a completely different subnet than your internal firewalls,which is quite handy if you want to do things like round robinNAT but are running out of IP address spaceon the subnet with your firewalls. With OpenBSD PF based firewalls,you can normally switch your NAT IPs without breaking

I recently read Amber Screen's A tale of /dev/fd ( via ) which notes an odd behaviorof Linux's /dev/fd and in fact of FreeBSD's /dev/fd as well, whereif you try to open a /dev/fd/N name for a file descriptor, it doespermissions checks and may refuse a process permissions to re-opena file descriptor it already has open. Screen writes:

To the dispassionate hacker (or a reader of Stevens),