I've retired my filtering HTTP proxy
I've been using a filter HTTP proxy for a very long time; thelast time I looked suggested that I'd been usingone for almost as long as they've existed. A couple of years ago, I wrote that it was time for me to upgrade the proxy I was using , because it had last been updated in 1998 andwas stuck having only HTTP/1.0 and IPv4. In my usual way of notdoing anything about pending issues as long as nothing
My new Linux home machine for 2018
Back in the fall I planned out a new home machine and then various things happened, especially Meltdown and Spectre(which I feel made it not a great time to get a new CPU ) but also my natural inertia. Thisinertia sort of persisted despite a near miss scare , but in the end I wound up losing confidence in my current (now old) home machine and justwanting to get things over with, so I bit the bullet and gota new home machine (and then I wound up with questions
Using a local database to get consistent device names is a bad idea
People like consistent device names, and one of the ways that Unixeshave historically tried to get them is to keep a local database ofknown devices and their names, based on some sort of fingerprintof the device (the MAC address is a popular fingerprint for Ethernetinterfaces, for example). Over the years various Unixes haveimplemented this in different ways; for example, some versions ofLinux auto-created udev rules for some devices, and Solaris andderivatives have /etc/path_to_inst . Unfortunately
Sometimes, not trying to reject some sort of spam is the right answer
I've written before about not doing anything about a temporaryspate of spam , and it remains a usefulguideline. But sometimes you're pretty convinced that certain spampatterns are long-standing, and it turns out that the right answeris still to not do anything, however reluctantly. As it happens, Ihave an example that we recently decided on.
One of the patterns we observe is that a decent amount of theattachments we get come from IPs listed in the Spamhaus Zen DNSBL . A further pattern
My current set of Firefox Quantum (57+) addons
It turns out that I use way more instances of Firefox than I reallyexpected, between my work laptop (in Linux and Windows), the onesI maintain for Twitter (on twomachines), test builds to track Firefox development, and so on.Although I'm still using Firefox 56 as my primary Firefox , I've upgraded all of these other instancesto Firefox Quantum, which has caused me to converge on a more orless final set of addons that I'm going to use when
The problem with Linux's 'predictable network interface names'
I find modern Linux auto-generated Ethernet device names to be a bigpain, because they're such long jumbles. enp0s31f6? enp1s0f0? Pleasegive me a break (and something short).
The fundamental problem with these 'predictable network interfacenames' is that they aren't. By that I mean that if you tell me that asystem has, say, a motherboard 1G Ethernet port and a 10G-T
The correlation between Spamhaus Zen listings and attachment types (March 2018 edition)
Our program to capture information about what sort of email attachments ourusers get logs not just the attachmentinformation but also whether or not the sending IP address waslisted in zen.spamhaus.org at thetime. For reasons beyond the scope of this entry, today I want tolook at the correlation between sending us attachments and beingin Spamhaus Zen, and what attachment types are popular. Becauseit's the most convenient option, I'm going to use four weeks ofrecent logs.
Over this time we
My uncertainties around X drivers for modern Intel integrated graphics
When I switched from my old office hardware to my new office machine , I got surprised by howwell the X server coped with not actually having a hardware driverfor my graphics card . That experienceleft me jumpy about making sure that any new hardware I used wasactually being driven properly by X, instead of X falling back tosomething that was just good enough that I didn't know I should begetting better. All of which is the lead up to me switching my homemachine over to new modern Intel
xprt: data for NFS mounts in /proc/self/mountstats is per-fileserver, not per-mount
A while back I wrote about all of the handy NFS statistics thatappear in mountstats for all of your NFSmounts, including the xprt: NFS RPC information .For TCP mounts, this includes the local port and at the time I said:
port: The local port used for this particular NFS mount.Probably not particularly useful, since on our NFS clients all NFSmounts from the same fileserver use the same port (and thus the sameunderlying TCP connection).
I then blithely talked about all of the remaining statistics
Our revised Dovecot IMAP configuration migration plans (and processes)
Back at the start of January, I wrote up the goals and problemsof our Dovecot IMAP migration , and inan appendix at the end I outlined what became our initial migrationplans. We would build an entirely new Dovecot server that was setup with people's IMAP mail folder storage being a subdirectory oftheir $HOME , say $HOME/mail (call this the IMAP root ), andthen we would get people to move to this server one by one. Migrationwould require them to change their clients