When I wrote about how Chrome may start restricting requests toprivate networks , I said that we have a split-horizon DNS setup, where people inside our network perimeter see different DNS thanpeople outside it. You might wonder why we go to the effort of havingsuch a thing, especially when it can cause problems with things likeDNS over HTTPS . One sufficientanswer is that it's required because we have public websites that areactually on private internal IPs , which meansthat people inside (who must talk to

In yesterday's entry about how Chrome may start restrictingrequests to private networks , Imentioned that we have various public websites that are actuallyon private IPs, as far as people inside our network perimeter areconcerned. You might wonder why. The too-short answer is that wedon't have enough public IPs to go around, but the longer answeris that it's because of how our internal networks are organized.

As a computer science department ,we have a bunch of separate research groups and professors

Chrome (and apparently Microsoft Edge) are likely to add newrestrictions on allowing things to talk to private network addresses(in a surprisingly broad sense). The reference for this is Feature:Restrict "private network requests" for subresources from publicwebsites to secure contexts ( via ), whichdescribes the first steps. The first steps Chrome is making is thatsuch "private network requests" may only be made from a publiccontext that is secure, ie from a HTTPS website instead of a HTTPone.

(As

The "amd64" architecture is what Go calls 64-bit x86 (often referredto as the more vendor neutral x86-64, although AMD did create it);it's the most common architecture on Unix servers these days. Aswe all know, the (64-bit) x86 architecture has evolved over theyears to add more and more instructions that cover more and moresituations. Some of these are various generations of vector/SIMDextensions (

Recently, the Prometheus host agent landed a commit (from a pull request ) thatexcluded the CPU iowait% from an example that showed 'CPU utilization'.Seeing this commit fly by got me thinking about our dashboards,where our overall 'system utilization' dashboard shows a 'non idletime' graph that includes iowait%. My current conclusion is thatour overview graph is correct for what we're interested in, butwhat we're interested in is not quite CPU utilization.

Generally iowait% is a

By and large, the people who develop Unixes have had a long standinginterest in faster boot times. Fast boot times look and sound good,and because parallelizing actions during boot is one obvious wayto speed it up, these faster boot times often come along with amore sophisticated view of service dependencies, which is usefulat other times. Although Linux's systemd is the current poster childof this effort, it predates systemd; predecessors include Upstart(on Linux), various reinvented service management frameworks, andSolaris

We're planning to get some high core count machines to be new computemachines in our environment of general multi-user Unix login servers,and in the process of working on this we found ourselves with animportant question: is it reasonably safe and secure to turn on simultaneous multithreading onmodern CPUs from either Intel or AMD or both? It's been surprisinglyhard to come up with a decent answer.

(For reasons beyond the scope of this entry, we can assume that SMTis worthwhile for us.

I've gotten a number of plain-text emails lately that contained boldtext (some of them were even non-spam emails). The innocent majorityamong you are wondering how on earth you get bold text into plain textemail, while the unfortunate minority are nodding and sighing aboutUnicode bold characters. For those who haven't run into this before, Unicode defines a number of additional codepoints for mathematicalsymbols that happen to be bold versions of regular Latin letters . Sincethese are Unicode codepoints, you can

Systemd has a long standing philosophical objection to waiting untilthe network is up; they have an entire web page on the subject . Neverthe less, we need to do this (like many sysadmins). I've writtenbefore about this , and if you're usingsystemd-networkd either directly or through Ubuntu's netplan, youcan in theory use systemd-networkd-wait-online.service .Usually it works, but today we discovered that it didn't on someof our Ubuntu 1