Notices by Chris Siebenmann (cks@mastodon.social), page 9

@isomer @ewenmcneill We had a DNS failure, and then machines stopped being able to access already-mounted NFS filesystems. Why? Because Linux NFS fileservers effectively re-validate clients every so often, and our exports use hostnames, and verifying hostnames uses DNS resolution. 😬

DNS: it's in everything.

As an online Canadian who reads and interacts with a lot of Americans (for the obvious reasons), American Thanksgiving is always a little bit weird. It's like, 'why is everything so quiet? Oh, right'. It's especially fun when I have work-related interactions with US things, because they generally aren't happening for three to five days.

@mhoye I think it's not dbus directly making the decisions there; instead I think there's some systemd magic to listen for dbus requests and then start things to answer them. Systemd also has a system to shut down 'inactive' things, but I don't know if it can tell whether a dbus thing is genuinely inactive, and some daemons will shut themselves down.

(If you think this can all go terribly wrong, yes, yes it can. Especially if things are not quite set right. We had fun experiences.)

This is my not-surprised face that people get a lot of their news from the online places where they regularly hang out, regardless of what those places are. It would be more surprising if they didn't.

(Call it a corollary of the MMO rule of socializing, which is that if you give people any means at all of talking with each other, no matter how limited and weird, they will do so.)

@divclassbutton @jannem @danluu It's funny to me that pro bicycle road racers have on the one hand not generally adopted something that could be a serious race advantage, but on the other hand do use lower-pressure tires (and maybe wider ones) on their bikes when they're doing 'classics' races over cobblestones. They've at least noticed that they race better some of the time.

Mechanical split keyboards are the kind of thing that looks cool when I see photos and writeups, but I in no way believe in enough to spend my own money without any experience.

In this they're much like recumbent bicycles, which I keep finding eternally cool and attractive in theory but not something I buy in practice.

Current status: reading about IPv6 address allocation plans and wondering if there are reasons to give any of our existing IPv4 subnets something larger than a /64.

(Our subnet firewalls don't run routing protocols so it's hard to see how multiple interior IPv6 networks on a subnet would work, even if people wanted to give, eg, their VM cluster an entire /64 for itself. Maybe it'd all work out?)

@janxdevil I think we could sort of do that but it'd be a bit awkward and I don't think we'd save anything. We do have one firewall that has a lot of subnets behind it, so in theory it would be a good candidate for a big prefix, but in practice we want to preserve our freedom to move some subnets to their own firewall if necessary (without renumbering things on them).

I guess we could use a prefix for the general firewall plus more specific routes for some.

@janxdevil DHCP-PD does seem to be close to ideal for the sort of consumer ISP environment descriptions of it make it sound like it was designed for. You delegate the prefix to your customer router cloud, you give each customer a /64 PD delegation, and if the customer gets renumbered some day, well, tough, you never promised them static global IPv6, they should be used to it from IPv4.

@janxdevil IPv6 scarcity thinking is nowhere near dead, sadly. Our local central networking people started out by suggesting that my entire department would have a /60. I had to break the news to them that we already had more (IPv4) subnets than that.

As a sysadmin, there's nothing quite like the feeling of working from home on the day that the machine room has a major power blip and subsequent ongoing problems. Almost all I can do is sit here.

Blog post: Network firewalls and Ethernet addresses, on some reasons why firewalls almost entirely work with IPs and don't have much support for MACs https://utcc.utoronto.ca/~cks/space/blog/tech/FirewallsAndMACs

(Firewalls not having good support for MAC-based actions is sometimes inconvenient, for example because Android devices don't support DHCPv6 for religious reasons.)

It turns out that if you nest a couple hundred <div>s inside each other before you get to the actual contant, GNU Emacs shr (its simple HTML renderer) can't cope with the result and gives you no content.

Guess what some HTML-capable email clients do (possibly after the email is repeatedly mutated and resent).

I wonder if I dare report this as an Emacs shr bug. Reproduction is simple, at least.

@bsmaalders @lanodan That's a good point; you really want every child to share the same read or write offset if stdin/stdout/stderr are files. And V7 didn't have O_APPEND, so you couldn't get the same effect for writes through that (and you'd still have issues with reads). So the dup() sharing semantics are actively required.

@lanodan I'm actually a bit curious about whether there's a deep reason for that dup() behavior or if it started as an artifact of an easy implementation (just increase the reference count on a file object in the kernel, no need to copy it and do stuff and etc etc). Especially since early Unixes had small limits on things like total open files; dup()'s sharing reduced pressure on them.

Yesterday I polled people on whether opening /dev/fd/N should act as if you'd dup()'d that file descriptor. The answer is 'no, that's terrifying'.

When you dup() file descriptors, the two fds share a bunch of state, especially including the IO offset in the file; meanwhile, open() promises a file descriptor with independent state. So turning open() into dup() may cause all sorts of fun surprises as changes to the current offset and other things on one fd are magically also on the other.

In retrospect I should have run this poll for 12 hours instead of 24, because I can't give my answer until the poll closes. In the mean time, I'm mostly sitting on my hands here.

@lanodan @jef The usual alternative to dup() is some special emulation of open(), although you maybe don't want to emulate too much of it, as I read about recently in http://phala.isatty.net/~amber/hacks/devfd

@lanodan @jef Yeah, there are a whole collection of fun bugs to the effect of 'open and/or dup returned 0, 1, or 2 by surprise, just look what broke'. Although it's not quite the same, since those FDs would already be open if you just returned N.

(You hit this bug if you start programs with 0, 1, and/or 2 closed, instead of open to /dev/null or something. These days a lot of things take care to always start programs with 0, 1, and 2 opened to *something* for this reason.)

@novenary @lanodan In practice TLS has a better monitoring story in Certificate Transparency than DNSSEC does. You'd need a lot of collaborators to hide a TLS certificate from CT; in DNSSEC I think it's potentially doable for an on-path network/DNS interceptor.

(You need to obtain the relevant zone keys, possibly through Official Demands From Authorities, but afterward who can tell?)