Namecheap, Grr

Yesterday qaz.wtf was briefly unavailable. The domain registration expired. This happened for number of reasons, some mine, some I'm going to blame on Namecheap.

First, what I did wrong: I put an overly strong spam filter rule in place that was marking all mail from them as spam. In particular the rule was indiscriminate about source when the domain was (a) using registrar-services.com for DNS and (b) using DNS with a SOA serial number that parsed as less than a day old. In fairness, it is a very effect rule. Here's a sample of the domains from the last 100 messages that deleted:

mail[.]forhealth[.]bar Oct 2020; medicarepro[.]xyz Oct 2020; diabetesfrepro[.]xyz Oct 2020; mail[.]diabetes2type[.]casa Oct 2020; carbosfix[.]xyz Oct 2020; mail[.]pocketdrone[.]work Oct 2020; goldplatedscoin[.]xyz Oct 2020; mail[.]fevertrhermal[.]casa Oct 2020; whowhpremium[.]xyz Oct 2020; mail[.]dxpgaget[.]work Oct 2020; mail[.]machinepower[.]bar Oct 2020; mail[.]trackerss[.]bid Oct 2020; royalbalance[.]cam Oct 2020; mail[.]pocketdron[.]work Oct 2020; stopsqribble[.]bid Oct 2020; shinehead[.]bid Oct 2020; mail[.]neckmassager[.]casa Oct 2020; audigrow[.]bid Nov 2020; mail[.]learnpiano[.]work Nov 2020; mail[.]heatromwave[.]casa Nov 2020; BayAreaTechSummit[.]com Nov 2020; mail[.]waxremove[.]casa Nov 2020; mail[.]gpstrack1[.]work Nov 2020; mail[.]gps1track[.]work Nov 2020; mail[.]zoom2dipro[.]casa Nov 2020; mail[.]strategys[.]bid Nov 2020; lifeprotect[.]uno Nov 2020; oxyrobot[.]bid Nov 2020; survivlife[.]uno Nov 2020; survivlife[.]uno Nov 2020; mail[.]musichall[.]casa Nov 2020; mail[.]discovery1[.]casa Nov 2020; mail[.]diabetesremedy[.]work Nov 2020; mail[.]zoomzoom[.]work Nov 2020; yourbusinesstips[.]biz Nov 2020; mail[.]goodhealth[.]casa Nov 2020; vanses[.]icu Nov 2020; mail[.]dailmulti[.]bid Nov 2020; mail[.]zoompro[.]casa Nov 2020; mail[.]heatpad[.]co Dec 2020; mail[.]foodgrow[.]bid Dec 2020; mail[.]shinehead[.]bid Dec 2020; mail[.]bagtrack[.]work Dec 2020; rewardtoshop[.]com Dec 2020; rivalo[.]com Dec 2020; rivalo[.]com Dec 2020; mail[.]techvisions[.]bid Dec 2020; mail[.]vestwoding[.]icu Dec 2020; brutualloss[.]icu Dec 2020; drawlace[.]buzz Dec 2020; 247blindco[.]co[.]uk Dec 2020; 247blindco[.]co[.]uk Dec 2020; 247blindco[.]co[.]uk Dec 2020; 247blindco[.]co[.]uk Dec 2020; mail[.]easysurveyrewards[.]best Dec 2020; zind[.]us Dec 2020; zind[.]us Dec 2020; herpesyl[.]icu Dec 2020; mail[.]digitalbrand[.]icu Dec 2020; mail[.]offertrend[.]icu Dec 2020; offerworld[.]icu Dec 2020; offerworld[.]icu Dec 2020; mail[.]offerhad[.]icu Dec 2020; healingsystem[.]icu Dec 2020; myshedesplan[.]icu Dec 2020; boosterday[.]best Dec 2020; brutualloss[.]icu Dec 2020; mail[.]shinehead[.]bid Dec 2020; mail[.]remedypro[.]us Dec 2020; tactnutri[.]icu Dec 2020; mail[.]feverfix[.]icu Dec 2020; mail[.]sugartonic[.]icu Dec 2020; mail[.]mechanism[.]icu Dec 2020; mail[.]ecomdeals[.]icu Dec 2020; mail[.]dealsbreeze[.]icu Jan 2021; mail[.]vestwoding[.]icu Jan 2021; mail[.]heatsawy[.]icu Jan 2021; mail[.]capitalreward[.]icu Jan 2021; mail[.]capitalreward[.]icu Jan 2021; mailserviceemailout1[.]namecheap[.]com Jan 2021; mail[.]energyy[.]bid Jan 2021; mail[.]speechrewards[.]icu Jan 2021; mail[.]usonly[.]bid Jan 2021; mail[.]certifiedstate[.]cam Jan 2021; thecsi[.]com Jan 2021; coloradocareerproject[.]com Jan 2021; mailserviceemailout1[.]namecheap[.]com Jan 2021; mail[.]healthrequired[.]work Jan 2021; mail[.]doorbellclub[.]work Jan 2021; mail[.]hollyb1ook[.]work Jan 2021; mail[.]safehealth[.]work Jan 2021; mail[.]remedypro[.]us Jan 2021; mail[.]yourtone[.]casa Jan 2021; mail[.]healthmonitor[.]casa Jan 2021; mailserviceemailout1[.]namecheap[.]com Jan 2021; mail[.]voidemodems[.]casa Jan 2021; mail[.]entend4ded[.]casa Feb 2021; mailserviceemailout1[.]namecheap[.]com Feb 2021; slotcrime[.]guru Feb 2021; mailserviceemailout1[.]namecheap[.]com Feb 2021

There are six messages, from two domains, that are inappropriately caught there. One of those was quasi-spam. Looking at the last 1000, there's only one more "ham" message caught. Seven out of a thousand is a pretty good track record, but when five of those seven are important that does sting. That's the part that's my fault.

Now onto Namecheap.

Almost all of my hostnames at Namecheap are set up to autorenew, with care selecting the ones that are not. At the same time, I have a credit card on file at Namecheap, and it is selected as my default payment method. I don't remember when, but I likely changed my card on file in late 2020, when I had a bunch of things to renew in the October to November period. I know I have twentish pieces of email from them in that period that didn't get deleted.

So it turns out that having autorenew selected and having a card on-file and "default is not sufficent to actually autorenew stuff. You also need to find the hidden configuration page (it is not the regular "edit card" page) that selects a card as enabled for autorenew. Serious, WTF?. Why isn't it with all the other configuration for a credit card?

Anyway, I use my own site regularly, and noticed the outage quickly. It did take a while for all DNS servers to get the message. I was seeing Cloudflare (1.1.1.1), eg, reporting the Namecheap parking page long after Google (8.8.8.8) had it restored.

Grrr.

Cherry Picking

One thing I have seen time and time again is people using two different branches of code for staging and production and then letting those branches slowly drift further and further apart.

I can fully understand staging should exist for testing stuff before you put it in production, but there should be a steady march of stuff that goes into staging and then maybe a few pieces get backed out, then all of staging syncs to production. Without the regular sync-ups, staging ceases to be an effective place to test things because it's not production + just these small changes but instead it's kinda like production but it has that, this, and some other differences.

But sometimes you have to deal with the hand you're dealt and can't ask for a reshuffle. Which brings us to git cherry-pick.

If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of "It's really pretty simple, just think of branches as..." and eventually you'll learn the commands that will fix everything.

I understand the "graph view" of git quite well. I still find the command line view of git to be a PITA. But it's a truism that people explaining Git get caught up that graph. Here's a page that came up in the first page of search results for git cherry-pick and provides a perfect example.

Once executed our Git history will look like:

    a - b - c - d - f   Master
         \
           e - f - g Feature

Yes, but how do I actually use git cherry-pick?

So with the background that my current most common environment has an "upstream" that represents the real (in-use) repo, a personal fork called "origin" (author dev), and a main (staging) branch of "master" and a production branch of "prod", here's a workable example of using cherry picking.

# If you have the same sort of setup, but haven't yet added prod
# locally, start with:
git checkout --track origin/prod

# Now switch to the prod branch
git checkout prod

# Make this current prod branch match the upstream prod.
# The rebase will discard your local prod history, but presumably
# the upstream prod history is what really matters
git pull --rebase upstream prod

# Now find some commit IDs that are in master but not prod
# and filter those with grep (the grep is optional, but may
# be very helpful). "master" here is a branch you've actually
# commited stuff to, and tested those commits there.
git cherry -v prod master | grep commit-description

# Armed with commits you want to apply, create a branch off
# your current prod to apply those
git branch -c PROD-CHERRYPICK

# Then use "git cherry-pick" to apply the commits to prod.
# If the diffs can be applied cleanly, this will completely
# "commit" the differences. If there are conflicts, you'll
# need to manually edit the files and select which set of
# changes are correct.
git cherry-pick commithash

# Changes applied, you can push that branch of prod to origin
# and make a pull request for origin PROD-CHERRYPICK to
# upstream prod
git push -u origin PROD-CHERRYPICK

Your workflow might not involve branching your origin "prod" for the changes, but it's a little cleaner and allows you to put a meaningful name on the branch. At $WORK, those meaningful names are by convention the Jira ticket names. It's a little awkward because I'll have a branch for PROJECT-NNN, apply that to master, then have to delete that branch and create a new one for my prod changes. The policy exists for the benefit of the computer code tracking my work, though. And poor simple computers are not great at subtly, so that's that.

Daylight Savings Time Sucks

The sooner we stop screwing with the clocks twice a year, the better.