the echothis blog – banging the corner does work sometimes
Recent Posts
I've ridden the wave from 3-guys-in-a-garage, to an acquisition by a big software company, and have built a string of startups since.
This blog is a little compendium of tips and tricks so hopefully the next guy doesn't have to reinvent the wheel.
P.S. the tagline is a sailing reference.
I took the plunge on upgrading on my main machine.
These were the hiccups:
I have a DisplayLink USB/DVI adapter for an external monitor.
The “compatibility check” Windows runs prior to upgrading failed to catch that I needed to install the latest driver.
It just was a blank screen after upgrading.
So I had to get it manually from
and fortunately it seems to be work (otherwise I’d have to rush out and buy a new adapter).
Vagrant somehow forgot the network interface it had been using prior and didn’t find the network interfaces installed.
Upon up, it asks “default: which interface should the network bridge to?” which is described in .
So I had to upgrade VirtualBox to the latest 5.0.x test build (which is semi-compatible with Windows 10), and upgrade Vagrant to v1.7.4 to work with it.
Then upon reboot and relaunch of Vagrant I was able to pick the interface I wanted (although it still seems to forget my selection each time).
My PuTTY keys quietly disappeared from the Pageant key list and had to be re-added manually.
Seem to work now though.
TortoiseGit overlay icons all disappeared as per this
which appears to point to OneDrive (which I have no intention of using) as the culprit.
I followed the steps in my comment there to work around it.
Still open: Windows Search was not indexing any program directories, so it couldn’t find any applications at all!
So I , and we’ll see if it works.
Recently I took over management of a WordPress site for a nonprofit that had been hacked at some point in the previous few months, and my job was to recover it.
It had been hosted at the time on GoDaddy and it appeared that there had been a GoDaddy-specific exploit that the hackers had known of.
Pretty quickly I found the hackers’ PHP files (for malware, it appeared) in both the webroot and under /wp-content/uploads – so those were quickly deleted.
I thought that was it, but I was wrong.
The site was running a somewhat-dated version of WordPress, maybe 3.9 – so it was 6-12 months old, which isn’t too bad.
It used a hodgepodge of plugins though, and I was afraid to upgrade it for fear of breaking some plugin (I had not budgeted any debugging time to this).
So I didn’t upgrade WordPress core, but should have in retrospect: as it turned out, there was also a spam-relay PHP hack under /wp-includes that I had missed.
When I got the site up on a new locked-down server, I didn’t notice at first that the postfix queue was getting absolutely hammered with outbound mails from this domain – which wasn’t hosting email in any case.
So I was in a situation where there were dozens of mails entering the queue per second.
I had no idea where they were coming from, as this server wasn’t even the destination of the MX records for the domain.
So I did the following:
Remove the MX records, and all associated A records (like email, smtp, webmail, etc.) from the zone entirely.
Now in hindsight I doubt it would have had any impact in this case, but if you’re not running mail on a domain, you don’t need any of that.
Check the mail queue via mailq and individual mails via postcat.
There’s more detail on syntax as this .
You can delete the entire queue via
nice postsuper -vv -d ALL&
To be safe, I also set up postfix to reject all emails being sent from this domain, by following the steps .
Eventually I thought to look at the access logs and found the hackers’ requests to /wp-includes which obviously is wrong.
I then did a clean reinstall of the WordPress core via git, and the outbound spam attempts ceased.
Moral of the story, always do a clean reinstall of the core.
Did another email migration, about 50K emails, to Google Apps last week, this time from a very ancient mail system on Verio.
A few more notes to add from this time around:
First step was to lower the TTL to 600 on the MX records.
Verio offers both an IMAP and POP interface, with ports documented .
The Verio username to authenticate the email account is the person’s mailbox name (e.g., “joe”).
It is not the username used to log into the Verio control panel.
This wasn’t documented anywhere.
If you use the latter, you can actually set up an IMAP account in Outlook with it, send and receive mails successfully (from joe’s account no less!), but no mail is synced.
So once I figured this out, I could set up an IMAP account and downloaded all 50K emails, 3GB worth, over the course of a day.
However none of the official migration tools from Google worked for various reasons:
was the first option, but failed since the Verio server lacks a valid SSL certification.
Verio also uses usernames (not email addresses) to authenticate IMAP, which the tool doesn’t allow.
Then tried GAMME, but never could configure it to authenticate with this ancient mail server.
Looks like it was using Dovecot but kept returning garbage.
Next option was
– but that doesn’t work since in this case we’re fetching from the same address, which isn’t allowed.
If the MX records still point to the old server I don’t see why they’d prevent this since that seems like a perfect scenario for this feature.
Then went to
for Microsoft Outlook – however, this only works on PSTs (generated by a POP account) and not the OSTs used by IMAP accounts.
This too, wasn’t documented.
So I had to spend another day syncing to Outlook via a new POP account.
So I then launched the tool but unfortunately, I could only get ~ 100 mails to sync at a time .
So I gave up on this.
This left me with only the “” option.
So I set up an IMAP account in Outlook for Google Apps, created a new folder in it, unsubscribed all other folders I could, disabled scheduled Send/Receive, copied all 50K emails from the Verio POP account to this, and then let it Synchronize.
Unfortunately Outlook throws an ugly error dialog and halts the synchronization when it tries to sync a message that’s bigger than 25MB so I had to keep manually restarting it.
Hopefully this is fixed in the next version of Outlook so it can continue in the background.
But a few days of this and everything finally made it up to the Google Apps folder.
I then logged into the webmail interface, and moved all the mails to the Inbox and deleted the temporary label.
Last, I switched the MX records to point to Google’s and raised the TTL to a more normal 3600.
Looks like it was all successful, and the email is in a much better, more reliable, and more secure system now.
I seem to keep forgetting the steps here, when I have to re-do it every few years.
Create a CA bundle file, in the proper order, via the steps .
In the Plesk dashboard (tested in v9.5.4), go to Home-&Domains-&-&SSL Certificates, and add a new one.
Paste in, or upload your certificate file for “Certificate” and the bundle file for “CA Certificate”.
I think the first time through, you may have to add in the private key file as well.
Go up a level to Web Hosting Settings and select the new certificate you just made.
Go to Home-&Services Management, and stop Apache and then start it.
This step may be extraneous.
You’re not done yet!
Now put the bundle file, certificate, and private key somewhere safe on the server filesystem.
The first two may now be in /usr/local/psa/var/certificates/ but it’s not clear they are ever used – at any rate we’ll ignore them.
Update /etc/httpd/conf.d/ssl.conf with the following:
# This seems to override whatever is in the domain VirtualHost.
SSLCertificateFile /path/to/domain_com.crt
SSLCertificateKeyFile /path/.key
SSLCACertificateFile /path/to/domain_com.ca-bundle
Now bounce Apache again.
You’ll see the new certificate.
If you run into trouble you can
for details on how to verify the SSL certificate being sent.