Recent comments on posts in the blog:

Transitional packages

I found that on my system all cases when your rm-and-reinstall procedure failed to clear the file off the obsolete list was exactly because of what you suspected—some other package than the one given by dpkg -S had installed the file in the first place. So for the record, dpkg -W can tell you which package to look for:

dpkg-query -W '-f=${Package}\n${Conffiles}\n' | awk '/^[^ ]/{pkg=$1}/ obsolete$/{print pkg,$0}'
Comment by klg
Let's make it obsolete files

Often I forget to clean up things like /etc/ssh/ssh_host_ecdsa_key (or dsa) or similar pieces that should be. Maybe you can include those (and other) as well.

Thanks for your insightful post.

Comment by Anonymous
Healthchecks

Recently I've discovered healthchecks.io, which is a free (and also FOSS) service that can check whether your mail server can deliver email.

The way it works: you configure a cron script on your server to send email to <uuid>@healtchecks.io, and if that email doesn't arrive for a set period (say, 24 hours, if you want one daily check), healtchecks.io will drop you a notification.

Comment by Marius Gedminas
Why encrypt DNS?

Why encrypt DNS when your browser still leaks the domain name via SNI extension, even though it runs over https? https://wikipedia.org/wiki/Server_Name_Indication

Comment by Jonathan
Re: comment 2

Not sure if dnscrypt-proxy caches but it doesn't seem that useful as general advise if it doesn't and everyone uses a proxy in Iceland.

I don't believe that dnsproxy-crypt caches (the name implies it doesn't), but Unbound does.

Comment by francois
comment 2
There is a reason why every ISP provides a recursor: latency. Every new connection that uses a name (unless cached locally with a caching resolver), every newly launched binary that connects somewhere needs to bear DNS latency. Not sure if dnscrypt-proxy caches but it doesn't seem that useful as general advise if it doesn't and everyone uses a proxy in Iceland.
Comment by Philipp Kern
Captive portals

FWIW, my usual solution to captive portals is to add some exceptions to the DNS resolution/HTTP proxy, which forces enough requests to go "directly" to be able to log into the captive portal. Eg, the domain of the place I'm staying in, and the domain of whatever Wifi provider they're using. Then I trigger the captive port by, eg, trying to go to the domain of the place I'm staying in. Over time one could accumulate a list of such exceptions required (and it seems like something that could be crowd sourced).

For better privacy one would perhaps want to selectively enable these exceptions based on the current location (and/or selectively disable them if at known locations like home/work/etc when it's not needed).

Ewen

PS: If your names are resolved from a location far away from you, you'll also generally get CDN nodes which are far away from you. Which may lead to poor performance. YMMV.

Comment by Ewen McNeill