GNU Emacs, Debian GNU/Linux, Linux, X.Org, Postfix, Perl, Python, PostgreSQL, OpenSSH, Firefox, Apache, ejabberd, Dovecot, git, GnuPG, XMonad, GHC, Gnus, jabber.el, rdiff-backup, LaTeX, Gimp, lots of GNU - the list goes on an on - thanks everybody!
It is - also - the season to upgrade your BIOS, it seems. Lenovo released an update for the Carbon X1 3rd, 1.21, just before new years. Here's a short note-to-self/reminder on how to update:
geteltorito -o boot.img n14ur20w.iso
dd if=boot.img bs=128k of=/dev/sdX(where
sdXis the device of your usb-stick, on my machine it was
The "Both"-thing is the one I usually forget (I have it set to Legacy only, normally).
By following these two guides: "Getting DKIM, DMARC and SPF to work with Postfix, OpenDKIM and OpenDMARC" and "How to eliminate spam and protect your name with DMARC" - I have installed and configured opendkim and opendmarc on my server, configured them (and Postfix) and added the accompanying DNS records, so now emails from
asjo.org get signed wit DKIM and I have set up DMARC records for the domains. (I had SPF-records set up a long ago already.)
Next year I'll get around to DNSSEC, I'm sure.
Update: if you have people with email adresses on your domain who use Gmail, they need to configure Gmail to use your smtp-server, and in
/etc/opendmarc.conf this option is needed:
IgnoreAuthenticatedClients true. Seems to work.
Last summer I was tumble drying my pillows and duvet, to try and keep allergy-triggering bugs down.
I usually never use the dryer, because it makes my clothes smell weird. But for the pillows etc. it was needed.
Unfortunately the tumble dryer kept triggering the RCD, turning power off in my apartment. This would happens around 4½ to 5 minutes after turning the dryer on, and to dry everything took quite a while longer. So it happened a number of times.
This meant that my cupboard server lost power aruptly. It coped remarkably well with that, except for one thing: one of the Dovecot mailboxes got corrupted: "Inconsistency in map index".
A quick search revealed that the tool to fix that is doveadm force-resync - "Repair broken mailboxes".
So I ran that on all the mailboxes, and it failed on one of them. Bummer.
More searching and reading up on mailing lists, I found someone reporting the same problem, and a note saying it was fixed in Dovecot 2.2.32 in commit c8be394.
This was a very nice piece of information, as I could quickly check that the version of Dovecot on my server was 2.2.27, and thus the fix could very well fix my problem as well.
I did not feel like upgrading Dovecot to a newer version, as I run Debian and rely on the security updates from the project, so I took a look at the commit, to see if the change was small enough that I could apply it to the Debian package locally.
Fortunately it is a 3-line change, so I got the source of the Dovecot package (
apt source dovecot), used quilt to add the patch, built the package with debuild and added it to my local package repository using reprepro.
After installing the patched package on the server I ran the force-resync command again, and lo-and-behold, the mailbox was fixed.
I 🖤 Free Software.
We work on and with Linux machines, use all the Free Software we can, and besides having quite a say on how to solve the problems, you also get to interact with a variety of smart colleagues from around the organisation - so you get to learn some microbiology as well.
If you're a curious developer who is good at programming and would like to work in Bagsværd - get in touch and send an application.
Update: time's up; deadline passed.
Here are two approaches to testing code that sends email, that I have stumbled over recently:
The difference in approach is thought provoking.
Why would you spend the time to implement something that simulates a real mail server, when you can just install a real mail server, and use it to test against?
Why would you test against a simulation (which might have its own set of quirks and shortcomings), rather than the real thing?
Kind of mind boggling to me. But that's apparently what's en vogue.
Unfortunately it seems to be full of holes.
After downloading and running a tool from Intel to check whether my system was vulnerable, Intel-SA-00086 Detection Tool , and getting the unfortunate message:
Based on the analysis performed by this tool: This system is vulnerable. Explanation: The detected version of the Intel(R) Management Engine firmware is considered vulnerable for INTEL-SA-00086. Contact your system manufacturer for support and remediation of this system.
I started looking for how to update the faulty code in my processor.
I found a description on how somebody updated their Lenovo X1 Carbon 5th gen, Solved: Re: X1 Carbon 5th gen on Linux: How to update Intel Management Engine 11.8 Firmware??, which was basically a couple of amendments to another guide: Updating Intel Management Engine firmware on a Lenovo without a Windows Install, which was written for a Gen 4.
Here is what I did to upgrade my Lenovo X1 Carbon 3rd gen running Debian unstable:
.exefiles from Lenovo, install the Debian packages
cabextract, and then run
innoextract n10rc02w.exe. This creates a new folder
cabextract SetupME.exe, which, among other folders creates one called
HECI_REL, which you will be using later. Put the
appfolder into a new folder:
mkdir winpe_overlay; mv app winpe_overlay/
wimtools. Wait until the Windows 10 iso has finished downloading, and then mount it:
sudo mount -o loop,ro Win10_1709_English_x32.iso /mnt
mkwinpeimg -W /mnt/ -O winpe_overlay disk.img
disk.imgto your USB stick, using
dd if=disk.img bs=128K of=/dev/sdX(where
Xis the letter of your USB stick,
bin my case), and boot he computer from it. If you haven't already, turn Secure Boot off, Legacy BIOS on.
cd \ cd app\HECI_REL\win10 drvload heci.inf cd \ cd app MEUpdate.cmdWait for the command to finish. For me it complained about
Shutdown.exenot being available at the end, so I just typed
exit, and that was enough to reboot the machine.
Running the detection tool now says:
INTEL-SA-00086 Detection Tool Copyright(C) 2017, Intel Corporation, All rights reserved Application Version: 126.96.36.199 Scan date: 2017-12-09 16:59:33 GMT *** Host Computer Information *** Name: tullinup Manufacturer: LENOVO Model: 20BSCTO1WW Processor Name: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz OS Version: debian buster/sid (4.14.0-1-amd64) *** Intel(R) ME Information *** Engine: Intel(R) Management Engine Version: 10.0.56.3002 SVN: 0 *** Risk Assessment *** Based on the analysis performed by this tool: This system is not vulnerable. It has already been patched. For more information refer to the INTEL-SA-00086 Detection Tool Guide or the Intel Security Advisory Intel-SA-00086 at the following link: https://www.intel.com/sa-00086-support
Yay.Author at Google+ Publisher at Google+