Blog | Admin | Archives | Random | Recent | Thanks
    • The shape shifters in their usual form.
    • Clippering under moody clouds.
    • 🌊
    • The City

Mega Life Update

In January, 2016, I moved to London to spin up a new Source Control team in London for Facebook. So far, the experience has been good — the team here is solid, and living in London has been a good experience. The main thing I need to do more of is travel to the rest of Europe.

In an age of easy sharing, it’s easy to get out of the habit of longer-form writing. However, I have found longer-form writing to be useful for me, so I’m going to strive for more regular updates in this place. I know many people have said such things before; let’s see how I do.

Expanding a RAID 1 array to RAID 10

A couple years back, I moved from a full tower for my file server to a small HP Proliant MicroServer (I’ve been very happy with this move). When I made that move, I went from 4x750GB in a RAID 10 configuration to only 2x750GB in a RAID 1 configuration. However, I keep taking photos and I noticed I was running out of space. Since I had the extra Hard Drives just sitting around, I decided to put them back into use. the hardest part was that there are only four HDD slots in the server, and I was using one of them for the boot drive.

However, I had long noticed that there was a 5.25 inch drive bay in the server that was conspicuously unused. All I needed was an adapter. It took me two years to finally get around to this project, but today was the day! I found a drive bay adapater and SATA power and data cables, then got to work. From a physical perspective, it was fairly straightforward once I had all the parts; the hardest part ended up being finding the extra SATA port on the motherboard.

I was a bit wary when I booted the thing — the hard drives I used had previously been a part of the 1.5TB array that the other two came from. Fortunately, everything went smoothly. It was then a rather simple matter of finding this excellent guide on ServerFault to rebuild the array into RAID 10 once again.

Yay technology; internet FTW!

How to Reattach to Screen When `screen -r -d` hangs

Based on an answer on serverfault, but modified to work on linux:

Use this one-liner to get the bash and sshd processes currently hanging onto the old screen.

ps aux | grep $(ps aux | grep [s]creen | grep -o 'pts[^ ]*') | grep 'sshd\|bash'

Kill these processes and screen is recoverable before the long and arbitrary timeout.

Hotel Room Security Fail

Here’s an interesting security flaw my friend and I discovered today…

Dovecot + Maildir + Ubuntu 14.04 LTS Upgrade

I recently upgraded the server behind this site to Ubuntu 14.04 LTS from 12.04 LTS (only about a year late!)

A few things went awry (the PHP install couldn’t talk to MySQL, for example), but a reboot cleared that right now. However, one piece remained broken. Mail wasn’t properly being delivered.

I’m don’t use this server for mail much myself, but some people (like my brother) do. It was broken, and I had no idea why. It didn’t help that the last time I touched the config was over a year ago. It also doesn’t help that mail server setup is basically a dark art. Regardless, after a few days of poking at it and “hoping the problem would go away”, I decided to go at it again today. Hopefully by writing this down I’ll remember a bit more about my setup, but if not, at least I’ll have this handy reference when I forget it again.

The way mail is set up on this server is that Postfix listens for incoming SMTP traffic, which it then forwards to Dovecot for delivery. Dovecot is set up to use the Maildir format, but instead of storing the maildirs in users’ home directories, it stores them in /var/mail/ since not all the users even have home directories. It made sense at the time, and I think it still makes sense now!

At any rate, with Dovecot’s upgrade came a problem, and after digging around, I saw in the logs that Dovecot was unable to deliver mail to /home//Maildir. Of course, those directories didn’t exist, so of course it was failing! However, I had set up the mail_location to be /var/mail/, so what was going on?

It turns out that Dovecot’s Ubuntu distro added a new configuration file, /etc/dovecot/conf.d/99-mail-stack-delivery.conf, which set the mail_location back to /var/mail/, and apparently the last place to set it wins (it was previously set in /etc/dovecot/conf.d/10-mail.conf). I commented out the offending line, and by tailing /var/log/mail.log, I could see that mail was once again delivering.

Now, I don’t know if this means it’s fixed; my brother will have to let me know. Regardless, it’s at least less broken now.

ZoomToScroll Chrome Extension

I made my first Chrome Extension today, after being annoyed by Chrome’s ctrl-scroll zoom anti-feature for far too long. I’m an avid user of the Ctrl-Click to open links in new tabs. Often I press Ctrl while I’m still scrolling, resulting in Chrome zooming the window I’m scrolling through, which is never what I want — I’ll use Ctrl-+ and Ctrl– for that, thank you very much.

I’ve searched several times before, but only today did I come across an extension, No MouseWheel Zoom, that is effective at stopping this annoying behavior.

However, it wasn’t exactly what I was hoping for. While it functioned as advertised, I actually would prefer to have the state of my Ctrl key ignored — ie, to be able to continue to scroll. I figured I’d take a look at the code of the extension and see if it looked doable.

Sure enough, it looked pretty straightforward, so I started hacking the extension, only to have Chrome disable it for security since it no longer had the same digital signature. Thus, it was time for me to learn how to create a new extension.

It’s actually pretty straightforward, and the documentation is quite useful as well. It wasn’t long before I had my own extension, which I called ZoomToScroll, written and tested. The next step was to package it an upload it, which was also straightforward. A one-time fee of $5 let me place it on the Chrome App Store, where you and anyone else can download it for free!

There are a few caveats to be aware of: I’ve only tested it on a single computer (my laptop), and it’s set up to scroll like a touch screen (that is, opposite of the old mouse wheel way). Also, different web sites seem to have different effects when Ctrl-scroll happens; some scroll speeds are faster while others are slower, and I don’t really care to investigate right now.

If this would be useful to you, feel free to download it and let me know how it works in the comments (or on the Chrome App Store).

Make mercurial use vimdiff the same way git does

At work, one of my favorite pastimes is getting mercurial to behave more like git.

Today, I decided to tackle merge conflict resolution using vimdiff.

Git has great support for this. In my .gitconfig, I have the following lines:

tool = vimdiff

Git is smart enough to run vimdiff with four panes — base, local, remote, and output. The first three windows are at the top, and the output window is at the bottom. Since it’s vimdiff, everything is colorized so you know what is happening, and the output has all the merge markers so you know what you need to fix.

Mercurial’s default seems to be a three-pane vimdiff view that has local, other, and base with no fourth pane to do the editing. This is, in my opinion, strictly worse.

I thought it would be straightforward, but I was wrong since the official documentation is wrong in a few ways (I may edit it, since it’s a wiki, if it’s easy, after I finish this post).

What I ended up with that actually works (using hg version 2.9.1 and vim 7.4) is adding the following to my .hgrc:

vimdiff.executable = vim
vimdiff.args = -d -c "wincmd J" $output $local $other $base
vimdiff.premerge = keep