The Advisory Boar
My headphone cable has become flaky, so I've been using a small external
speaker for a while. I now need to change my volume settings so often
that running alsamixer in a terminal each time was beginning to annoy
me. So I looked for a systray-based mixer (I use xmobar with xmonad),
and I found volumeicon
(packaged in Debian as volumeicon-alsa).
I really like volumeicon. The default behaviour is perfectly sensible.
Click the icon to mute, click again to unmute. Hover to see the current
volume level, use the scroll wheel to change it. Middle click to "Open
Mixer", which runs alsamixer in a terminal. Right click to set
What's more, the preferences are also remarkably sensible. You can pick
the ALSA device and channel to control, and there's a straightforward
menu to change the appearance and behaviour of the icon.
It's been quite a while since I encountered a new program that did
exactly what I wanted with so little fuss.
I use xmonad, which needs ghc.
On my Debian 9/stretch machine, the manpages-dev package is declared to
break libbsd-dev, which ghc depends on. So in practice, one must choose
between xmonad and manpages-dev, which has annoyed me for a long time.
Today I tracked down a
related Debian bug report
and happened to notice that my libbsd-dev 0.8.3 was just one minor
revision too old to avoid the conflict declared by manpages-dev 4.10-2:
$ apt-cache show manpages-dev|grep Breaks
Breaks: libbsd-dev (<< 0.8.4-1), manpages (<< 4.13-3)
I also noticed that
packages were available in unstable/sid, and followed the
instructions to create a backport
of the package to stretch.
$ dget -x http://http.debian.net/debian/pool/main/libb/libbsd/libbsd_0.9.1-1.dsc
$ cd libbsd-0.9.1
$ sudo mk-build-deps --install --remove
$ dch --local ~bpo9+ --distribution stretch-backports "Rebuild for stretch-backports."
$ dpkg-buildpackage -us -uc
I installed the updated libbsd0 and libbsd-dev packages, and was then
able to install manpages-dev for the first time in… several months, at
I have manpages again!
Here's how I configured Postfix to relay mail from email@example.com through
smtp-relay.gmail.com:587 using the credentials set up for firstname.lastname@example.org
on Google Apps.
There are three parts to this: making Postfix relay mail based on the
sender address, teaching it to authenticate to gmail, and configuring
gmail to accept the relayed mail. (Postfix was already configured to
send outgoing mail directly.)
I created /etc/postfix/relay_hosts with the following contents:
Then I ran «postmap /etc/postfix/relay_hosts» and set
SMTP SASL authentication
I created /etc/postfix/sasl_passwords (mode 0600) with the following
Then I ran «postmap /etc/postfix/sasl_passwords» and added the following
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
That enables SMTP AUTH in the Postfix SMTP client and tells Postfix
where to look up the username and password for a domain.
Gmail will accept SMTP AUTH only in a TLS session, so
TLS client support
must be configured in Postfix (which means setting
to "may"). But even once that's done, gmail advertises only the
following authentication mechanisms:
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
I didn't want to worry about OAUTH, so I was left with PLAIN was the
only reasonable choice. Postfix will not use plaintext authentication
mechanisms by default, so I also had to remove "noplaintext" from the
default value for
As an additional precaution, I also set
to change the default TLS policy from "may" to "encrypt" for
When I tried to send mail through the relay, Postfix wasn't able to
SASL authentication failure: No worthy mechs found
SASL authentication failed; cannot authenticate to server smtp-relay.gmail.com[126.96.36.199]: no mechanism available
Google considers password authentication to be “less secure”, and you
have to explicitly enable it on the
less secure apps settings page.
There are some
but I was happy to take the path of least resistance here.
I did that and tried again, only for mail to bounce with this error:
Invalid credentials for relay [188.8.131.52]. The IP address you've
registered in your G Suite SMTP Relay service doesn't match domain of
the account this email is being sent from. If you are trying to relay
mail from a domain that isn't registered under your G Suite account
or has empty envelope-from, you must configure your mail server
either to use SMTP AUTH to identify the sending domain or to present
one of your domain names in the HELO or EHLO command. For more
information, please visit https://support.google.com/a/answer/6140680#invalidcred
This message is misleading, as I found out by using openssl's s_client
to establish a TLS session and then authenticating by hand. SMTP AUTH
succeeded, but MAIL FROM was subsequently rejected.
I followed the
link in the message,
which led me to the
SMTP relay service
The Google Apps admin console doesn't use sensible URLs, but I followed
the breadcrumb trail to an “Advanced settings” page where I was able to
edit the SMTP relay service settings to set “Allowed senders” to “Only
addresses in my domains”, as well as to “Require SMTP authentication”
and “Require TLS encryption”. Remember to “Save” the changes.
The error I got was because the “Only accept mail from specified IP
addresses” option was checked for this particular domain. I could have
added the IP address of my server to the list, but SMTP authentication
was what was I wanted to use anyway.
I wanted to restore a clean Raspbian image on the Raspberry Pi that was
running in the battery room. I could have gone and got it, but I would
have had to climb a ladder.
So I thought “Why not just remount the filesystems 'ro' and dd the image
I remounted / and /boot (after "systemctl isolate rescue.target", which
stopped sshd but left my ssh session running) read-only, and dd'ed the
image from an NFS mount onto /dev/mmcblk0. The dd worked fine. I used
/proc/sysrq-trigger afterwards to sync and reboot (I couldn't run any
binaries after the dd, which wasn't much of a surprise). The machine
fell off the network as expected…
…and never came back up. So I climbed up the ladder and brought the Pi
down to my desk and plugged it into my monitor. It did start to boot,
and got a fair distance before the kernel panicked. I didn't bother to
try to figure out the problem, just extracted and rewrote the SD card;
and all was well thereafter.
But I still think my plan ought to have worked.
My mother called to tell me that people were complaining that mail sent
to her address at one of my domains (menon-sen.com) was bouncing. Here's
an excerpt from the bounce message she sent me:
DNS Error: 27622840 DNS type 'mx' lookup of menon-sen.com responded
with code SERVFAIL
I thought it was just a temporary DNS failure, but just for completeness
I tried to look up the MX for the domain, and got a SERVFAIL response. I
checked WHOIS for the domain and was horrified to find this:
Name Server: FAILED-WHOIS-VERIFICATION.NAMECHEAP.COM
Name Server: VERIFY-CONTACT-DETAILS.NAMECHEAP.COM
In a near-panic (because this meant email to one of my work addresses
was also being bounced), I checked a bunch of stuff: No, the whois
details for the domain were not incorrect (nor had they been changed
recently). No, Namecheap had not sent me any whois verification mail
about the domain. No, Namecheap had not sent me any notification that it
was going to suspend the domain. No, the Namecheap admin page didn't say
anything about the domain having been suspended.
I couldn't find any relevant articles in the support knowledgebase, so I
opened an emergency ticket with Namecheap support. They responded in an
hour, and helped to resolve the problem immediately. They did admit that
I didn't receive a notification because of an error on their part:
We have double-checked contact details on the domain in question and
registrant details appeared to be missing on the domain due to a
one-time glitch at our end. That is the reason you have not received
verification email. Please accept our most genuine apologies for the
inconvenience caused you.
I have always found Namecheap support to be responsive and helpful. I do
appreciate their candour and the prompt response in this case as well,
but I am deeply shaken that their system has no controls in place to
prevent a domain from being suspended without any sort of notification
(especially since they were sending me notifications about other domains
registered under the same account in the same time period).
I don't know when exactly the domain was suspended. I have actually lost
mail because of this incident—and at least one of them was an important
response to some mail I sent. But thanks to my mother's correspondents,
I think the problem was discovered before very long. I cannot afford to
worry about this happening for my other domains that are up for renewal
in the near future. If the same thing had happened to toroid.org, it
would have been catastrophic.
I have been a happy customer of Namecheap for more than five years, and
recommended it to any number of friends during that time. Along with
(which is much more expensive), it's by far the best of the dozen or so
registrars I've used over the past two decades. I have no idea where to
move my domains, but I'll start keeping an eye out for an alternative.
Update, moments after writing the above: my friend Steve points
out that there's something to be said for having a vendor who admits to
their errors honestly; and only a pattern of errors rather than a single
incident would justify moving my domains away to an unknown registrar.
A few days from now, I hope to be able to properly appreciate Steve's
wisdom in this matter. Meanwhile, I'm saved from precipitous actions by
the fact that I haven't the faintest idea where to migrate anyway.
I have more than a passing interest in VPN software, and have looked at
and used many different implementations over the years. I haven't found
much to cheer about, which led me to write
for my personal use.
I've been reading about
for the past few weeks, and I really like it so far. It follows through
on many of the same goals that I had with tappet, and goes much further
in areas important to more widespread adoption. The author,
articulates the project's design goals in
Keeping the code small and easy to review was a primary consideration
for me (tappet is under a thousand lines of code, not including NaCl).
By this measure, Wireguard does an admirable job of staying small at
around 15,000 lines including crypto code and tests.
When I wrote tappet, the
did not exist in a usable (or recommended) form. Wireguard's adoption of
this framework brings a host of desirable properties that tappet lacks,
notably including perfect forward secrecy.
One of my major frustrations with OpenVPN is the extraordinary time it
takes to establish a TLS connection on a high-latency link. Very often,
when tethered via GPRS, it will retry forever and never
succeed. Tappet goes to the other extreme—it requires zero
setup for encrypted links (at the expense of perfect forward secrecy).
Wireguard restricts its handshake to a single round-trip, which is an
entirely acceptable compromise in practice.
Wireguard runs in the kernel, thereby avoiding the need to copy packets
in and out of userspace. I didn't care nearly as much about performance.
Tappet is fast enough in userspace that it keps up with the fastest link
I've tried it on (42.2Mbps DCHSPA+), and I didn't need anything more.
Wireguard accepts multiple peers per interface, while tappet is limited
to setting up point-to-point encrypted links. The former is obviously
more practical in realistic deployments. (On the other hand, Wireguard
is a Layer-3 VPN, while tappet operates at L2 and forwards Ethernet
frames instead of IP packets. How much that matters depends on the
I look forward to a time when I can use Wireguard in production.
Hassath's birthday present this year was an
(with 8GB of Kingston DDR3L RAM and a 250GB Samsung SSD 750 Evo) to
stand in at home for her ageing Thinkpad X131E.
It took some time for the machine to reach our remote mountain abode,
but we have it working nicely after spending a few hours wrestling with
it. Here's a quick summary of our experience
wasn't really useful).
Hassath loves her old Samsung SyncMaster 172s monitor (1024x768, VGA)
and resists the idea of a new wide-format monitor. Getting the NUC to
work properly with this display took the most time (but none of it was
the display's fault).
We connected the monitor to the NUC's VGA port and were greeted with a
"Video mode not supported" error on the monitor. The debian installer's
text-mode display worked fine after boot, but we couldn't see any of the
UEFI setup menus. Fortunately, we were able to sidestep the problem by
using an HDMI→VGA adapter that we had ordered “just in case”. Using the
HDMI output resolved the display problems with the UEFI menus.
After we installed Debian (8.1 from a USB stick created from the DVD
image), X wouldn't start. The intel driver didn't work, and Xorg fell
back to the VESA driver, and
died while trying to set the video mode.
(Also, virtual terminals didn't work at all until we added an xorg.conf
snippet to force the resolution to 1024x768.) It didn't work even with
the DVI-D input (via another “just in case” HDMI→DVI-D cable) on my
We stumbled around for a while, but we eventually got it working. The
key was to apt-get dist-upgrade against jessie-backports to install a
new kernel and drivers (e.g., libdrm-intel1). We also updated the BIOS
from revision 0054 to
but I am not sure that this was necessary, or even helpful. Xorg works
with the new kernel and Intel driver. We didn't bother to check if the
VESA driver would also work if we forced its use.
(Aside: we had no UEFI boot-related problems at all. We didn't even need
to try the legacy boot option, either for the installation from the USB
stick or to boot the installed system.)
Everything else worked
The Ethernet controller is a Realtek RTL8168h, which works out of the
box with the r8169 driver. Installing the firmware-realtek package got
rid of an “unable to load firmware patch” message, but the adapter
worked fine without it.
The wireless controller is an
Intel dual band wireless-AC 3165,
which required the new kernel from backports (4.8, though 4.2+ should
have worked from what we read) and the firmware-iwlwifi package to be
installed. It worked fine thereafter.
The audio controller is an Intel "Braswell" 2284, which works out of the
box with the snd_hda_intel driver. Audio output goes simultaneously to
the headphone connector on the front panel and the glowing red S/PDIF
plus headphone connector on the back. We did not try S/PDIF audio (no
cable, no devices) or HDMI audio (no audio port on the HDMI→VGA
adapter) or recording (no mic—or at least, no mic on my desk).
The Intel Bluetooth 4.0 controller (8087:0a2a) works out of the box with
the btusb driver. We were able to pair with an Android phone and a
Bluetooth speaker. We were not able to play audio to the speaker, but
that is probably not a problem with the NUC, because we didn't manage to
get it working with any of our other machines either.
We didn't try the SDXC card slot or the infrared sensor.
Update (2017-01-18): The SDXC card slot works fine. I used it to
write a Raspbian image.
A friend had a domain registered at 123-Reg that he no longer wanted. It
was coming up for renewal later this month, and he offered to transfer
it to me. The domain was not locked, so I asked him for an auth code,
and immediately submitted a request to transfer it to
my preferred registrar.
The transfer failed, and Namecheap sent me mail saying the domain was
locked. I checked, and it was. It had also already been transferred to
another sponsoring registrar (Mesh Digital, the company that owns both
123-Reg and Domainmonster). My friend contacted support to unlock the
domain, but by then of course the domain had entered the sixty-day
period during which it could not be transferred again. I was forced to
pay the renewal fee to them, and will now have to retry the transfer
after the embargo expires.
I suppose I could think of benign explanations for the above if I tried,
but I'm not feeling especially charitable about it.
I got my dad a
Lenovo Yoga 300
a few days ago, and installed Debian 8 on his old Ideapad S206 before
giving it to Ammu, who has been using my old (and increasingly broken)
for months now.
The Linux Laptop Wiki has a page about the
the quick summary is that everything works with only a little tweaking.
Wifi worked out of the box with brcmsmac. Bluetooth worked fine after
installing the firmware-atheros package. Sound input and output worked
fine out of the box. The hotkeys to change the volume (and brightness,
etc.) also worked. I didn't try the card reader or the webcam.
I didn't bother with the fglrx video drivers, but I had to install
firmware-linux-nonfree to enable KMS (kernel mode setting) to get
suspend/resume to work properly. (Hibernation worked fine anyway.)
This is a sleek and light machine, quite a step up from the earlier
Ideapad models I've used. The screen is a bit shiny, but stops short of
being annoying. The keypad is unfortunately very jittery—unless you are
very deliberate about tapping-to-click, you'll most likely just move the
pointer a bit rather than clicking. This was my father's biggest problem
with the machine (and it wasn't just a matter of acceleration settings).
But it's working nicely otherwise, and I hope Ammu gets some good use
out of it.
An article about
reminded me of a problem I investigated last year when Hassath couldn't
send mail when connected through her phone's mobile hotspot.
My first response to any network problems is to run tcpdump, and I saw
the following EHLO response from my own SMTP server.
250-AUTH PLAIN CRAM-MD5
Vodafone is transparently proxying outgoing SMTP traffic and replacing
STARTTLS in the EHLO response with XXXXXXXA, so that the client doesn't
try to negotiate TLS. If you issue STARTTLS anyway—which no normal SMTP
client would, but openssl's s_client can do—the TLS negotiation fails.
So it's not just a downgrade attack, it's actively sabotaging TLS
This was the case in mid-2014, and it's still the case at the time of
writing. I wonder how many terabytes of email logs they have collected
in the meantime, how they are stored, and who is reading them.
While I was tethered to my phone, I did a bit more testing. Vodafone
India doesn't seem to mess with HTTPS connections, and IMAP connections
are not downgraded either (i.e., the server's STARTTLS advertisement is
not modified, and the TLS negotiation succeeds). Nor did it inject any
Update (2017-10-01): I
happened to read a 2014 post by Steve Atkins titled
STARTTLS and misplaced outrage,
which says this is a "very, very, very well known" problem with the
configuration of a PIX firewall feature named "MailGuard". He writes:
The most likely scenario, by far, is that the mailserver operator is
behind a PIX, and has it configured like that. As port forwarding is
specific to the interface that traffic comes in on, it’s quite possible
that it’s only misconfigured for traffic coming over some networks.
Drastically less likely is that there was a PIX installed – backwards –
on the cellular providers network.
Somewhat less likely still is that they’re simply lying about what
they’re seeing. But those are the only three options.
In this case, I'm the operator of the mail server in question, and I
know there is no PIX involved anywhere, and I know I'm not simply lying
either. I also know that the problem happens only on Vodafone's network,
so—unlikely as it may be—maybe there's a PIX installed backwards on the