<![CDATA[ Thomas R. Hall]]> https://www.trhall.org <![CDATA[ Frictionless Text-Based Blogging ]]> https://www.trhall.org/frictionless-text-based-blogging https://www.trhall.org/frictionless-text-based-blogging Wed, 21 Mar 2018 00:00:00 -0400 I haven’t updated this site for a long time. Why? In one word: Friction. I had a hacker-based approach to editing blog posts that involved a combination of git, Jekyll, shell scripts, renewing my own Let’s Encrypt certificates, and more. All of those little tasks meant I was spending more time maintaining my blog than writing. That had to change.

Recently, I was having lunch with a friend and former coworker. He mentioned Blot to me. The website didn’t look too hot on my phone. I know, I know.”, he said. Give it a chance on the computer.” I’m glad that I took his advice.

Blot is a blogging platform. Once I saw that Blot wasn’t afraid to list former and current competitors, I knew that I wanted to give it a try.

You configure Blot via its web dashboard, but that’s all you can do online. You can’t edit blog content there. Blot uses regular text files, Markdown files, images, and more, and makes blog posts out of them. How do you edit and maintain things? You store files in Dropbox. Blot monitors a shared Dropbox folder and once it notices a change, it pulls in the updates and generates or updates blog posts.

This means I can use any text editor I want, on any platform, as long as I can save a file to Dropbox. Game. Changer.

Blot Features

There are many features described on the Blot help site, and if you want to get more in-depth by customizing further, you can visit the Developer site to see how to make your own theme and other customizations.

Some of the things I like about Blot:

  • Editing content via any editor that can modify Dropbox content
  • Ability to use Markdown
  • Handles drafts and future-dating posts
  • Pages, Posts, and other content
  • Theming, including building your own
  • Web-based dashboard for configuration
  • Ability to use your own domain
  • SSL-enabled by default, using Let’s Encrypt
  • Ability to live preview drafts
  • It’s paid ($20/year per site), so it won’t just disappear

Migrating from Jekyll to Blot

Migrating from Jekyll to Blot was easy. There are scripts that convert Tumblr, WordPress, Jekyll, and Squarespace blog posts. I didn’t have that many pages, so it was easy for me to simply modify the files I had to work with Blot.

I started with the following folder structure:


I simply put my Jekyll _posts files into the posts folder, moved any static pages into pages, and renamed my assets folder to _assets.

I then modified the metadata at the top of each post to remove the yaml header --- and made some other minor changes:

  • Renamed excerpt to summary
  • Comma-separated tags

I then went to the dashboard and modified a few settings, including configuring my custom domain, permalink structure, Google Analytics code, and a few other items. Blot automatically configured my Let’s Encrypt SSL certificate and more.

I was able to migrate my site in about 30 minutes, using one of the default themes.

Next Steps

I’ll work on migrating my existing theme over to Blot, and will also post about editing entries from mobile devices.

Now I have a site I can edit anywhere with very little friction, I hope to keep the site updated more regularly. In fact, this post was whipped up in about 10 minutes on my Mac in iA Writer.

<![CDATA[ Migrating Let's Encrypt Clients - From Certbot to Google ACME ]]> https://www.trhall.org/migrating-lets-encrypt-clients-from-certbot-to-google-acme https://www.trhall.org/migrating-lets-encrypt-clients-from-certbot-to-google-acme Thu, 29 Dec 2016 00:00:00 -0500 In my post about Using Let’s Encrypt for Automated SSL Certificates, I discussed using the official Let’s Encrypt client, formerly called letsencrypt-auto, now called certbot. While Certbot is the official client, I disliked how heavyweight it is. You have to have Python, virtualenv, and may other ancillary tools installed in order to get it running. There had to be a better way.

Fortunately, there is. Actually, are. Multiple. There are several clients available, written in a variety of tools. But I was looking for something that not only supported the original HTTP challenge method, but also the newer DNS method. I also wanted a client that didn’t require installation of lots of tooling. I wanted a simple program that was standalone and cross platform. For me, that meant looking into a client written in Go.

While there are other Go implementations, many of which may be more feature-rich, Google ACME is written by some Google employees. Even though it isn’t an official Google tool, it looks well-written and is maintained. The official README has great documentation for how to use acme, including setting up a new account. I won’t repeat those instructions here. Installation is literally as simple as downloading a binary.

If you’re setting up from scratch, this is very easy and is the way to go. If, however, you already generated certificates using the official certbot client, then you may want to keep your existing account and certificates.

(Optional) Migrating a Let’s Encrypt account created with certbot to Google acme

Again, this section is only necessary if you want to migrate an existing Let’s Encrypt account that is configured with certbot to use Google acme. If you don’t need to do this, skip to the next section on Certificate Generation.

There are a couple of steps in order to migrate from an existing account created with certbot to acme, since they store keys and configuration in different formats:

  1. Create account.json file
  2. Convert account key
  3. Confirm the account is set up

Create account.json file

Before we convert your account key, we need to get the basic configuration for acme set up, which includes creating the account.json file. Since this format is specific to acme, you need to create it. Since I didn’t have a sample to use, I ended up running the setup process against the Staging server first. This generated a new key and an account.json file. I then modified the json file to have the appropriate production values for my ID and the URI.

To save you the hassle, you can use the following example below and just copy/paste in your values:

  "URI": "https://acme-v01.api.letsencrypt.org/acme/reg/<id>",
  "Contact": [
  "AgreedTerms": "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf",
  "CurrentTerms": "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf",
  "Authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
  "Authorizations": "",
  "Certificates": "",
  "ca": ""

This content goes into a file named account.json, which lives, by default, in the $HOME/.config/acme/ directory.

Convert account key

Since certbot and acme use different formats to store configuration and keys, we need to convert the account key. I followed the steps under the Option 2: Use existing letsencrypt account key section from Secure Your letsencrypt Setup With acme-tiny, which uses Jon Lundy’s conv.py Python program to do the conversion.

The steps are:

$ wget -O - "https://gist.githubusercontent.com/JonLundy/f25c99ee0770e19dc595/raw/6035c1c8938fae85810de6aad1ecf6e2db663e26/conv.py" > conv.py
$ cp /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/<id>/private_key.json private_key.json
$ openssl asn1parse -noout -out private_key.der -genconf <(python conv.py private_key.json)
$ openssl rsa -in private_key.der -inform der > account.key
$ rm conv.py private_key.json private_key.der

Once this is done, you’ve decoded the key from the certbot private_key.json file and now have a standard RSA key file, account.key which is what acme uses.

Put the account.key file into the $HOME/.config/acme/ directory, which should already exist based on the earlier step.

Confirm the account is set up

Ensure that your configuration file and key are correct by running the following two commands, which will first verify your account is set up correctly, and also ensure that you’ve agreed to the latest Terms of Service.

acme whoami

Which will produce output similar to:

URI:         https://acme-v01.api.letsencrypt.org/acme/reg/<id>
Key:         /home/<username>/.config/acme/account.key
Contact:     mailto:example@example.com
Terms:       https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf
Accepted:    yes

If you don’t see Accepted: Yes above, be sure to run the next command.

acme update -accept

Which should produce output similar to above, including the Accepted: Yes line.

Okay, now that we’ve migrated our account, let’s generate a new cerificate with it.

Certificate Generation

If you used the default settings for creating your account key and json file, you simply need to run the acme client like this:

acme cert example.com

If you want to run it and use the DNS challenge method use this instead:

acme cert -dns=true example.com

(This will require that you create a TXT record to verify your ownership of the domain, but only needs to be done once.)

When the command finishes, your new certificate and private key will be stored in the same directory as your configuration. The files will be named similar to:


Now, all you need to do is change the nginx config to reference them.

Nginx Configuration

Update your nginx configuration (explained in more detail in a prior post) to have the following in your includes/letsencrypt-ssl file:

ssl_certificate     /home/<username>/.config/acme/example.com.crt;
ssl_certificate_key /home/<username>/.config/acme/example.com.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

And that’s it!

<![CDATA[ Using Working Copy for Mobile Blogging ]]> https://www.trhall.org/using-working-copy-for-mobile-blogging https://www.trhall.org/using-working-copy-for-mobile-blogging Mon, 28 Dec 2015 00:00:00 -0500 Working Copy commit dialogWorking Copy commit dialog

In my previous post on setting up Jekyll to publish to GitHub Pages, I mentioned some alternative ways to post content to a Jekyll blog. Since I’m using GitHub Pages and the Git version control system, things aren’t as simple as dealing with a file and directories on my monitor device. Or is it? This is where Working Copy for iOS comes in.

I use the following tools when blogging from iOS:

  • iPhone or iPad - I can use one or the other, or both, if I’m keeping content synchronized with the server.
  • Working Copy - Used to manage my Git repositories on GitHub.
  • Editorial - Has enhanced Markdown editing capabilities, a quick swipe to preview content mode, and other custom workflow capability using Python. Integrates with Working Copy via an installable workflow.
  • Swype or a Bluetooth Keyboard - If I happen to have a Bluetooth keyboard, I’ll use it. Otherwise, Swype allows me to quickly type content with a finger or stylus.

While Editorial and a faster input method are certainly not required, they do speed up my ability to create content.

An Aside: Version Control Systems

Before we dive in too deep, is helpful to understand what a distributed version control system like Git is. Basically, think of GitHub as the master or authoritative source of your content.

When you clone a repository to your local machine, you can make modifications. But if you want the master repository to reflect these changes, you have to send those changes back. In Git terminology, you are committing and pushing changes back to the master repository.

Similarly, if you want to reflect changes pushed to your master repository from other devices, you need to fetch those changes and merge them into your local repository. This allows you to see any modifications and also merge differences you may have made to the same article on multiple devices.

Setting up Working Copy

Working Copy can work with multiple repositories. So if you have multiple blogs, you can edit and maintain them all. Setup is fairly simple:

  1. Authorize access to your GitHub account, if you haven’t already (a one-time action)
  2. Clone a repository
  3. There is no Step 3

Working Copy Clone repository choiceWorking Copy Clone repository choice

Click the plus sign in the top right of the Repositories pane on the left side of the screen. Choose Clone Repository, select GitHub, then select the repository you’d like.

Working Copy Clone repository dialogWorking Copy Clone repository dialog

Adding/Modifying Content

Now that you have a local copy of a repository, you can add or edit content. Navigate to the location you want to add content in the repository browser pane on the left and then click the plus button. You can create a new text file, import images, or add other files to your site.

Working Copy Add item dialogWorking Copy Add item dialog

  • Create/edit content
  • Commit changes

Working Copy changes pending uploadWorking Copy changes pending upload

Once you’re ready to push your changes, simply swipe left on your repository and choose Commit. You’ll also notice an option to Fetch. It’s best practice to fetch remote changes before you commit your changes, so I would fetching/merging and then committing.

Working Copy changes commit fetchWorking Copy changes commit fetch

Synchronizing Changes Made Elsewhere

Oftentimes, you may have made changes elsewhere. Maybe your desktop or another mobile device. In these cases, you need to update your local copy. Swipe left on your repository and choose Fetch, then swipe left again and choose Merge.

Unless you have conflicting changes, everything will automatically synchronize”. Once you’ve merged in remote changes to once fetched, your local repository is current.

A Concrete Example

This post was composed on an iPad. Screenshots were taken on the iPad, cleaned up using some editing tools, then optimized using Kraken.io. Images and the post were uploaded to GitHub via Working Copy.

Working Copy Rename FileWorking Copy Rename File

Once I was satisfied with the draft, I renamed the file to include the date in the file name. This tells Jekyll that the post is no longer a draft and should be published.

<![CDATA[ Hosting a Blog on Jekyll and GitHub Pages ]]> https://www.trhall.org/hosting-a-blog-on-jekyll-and-github-pages https://www.trhall.org/hosting-a-blog-on-jekyll-and-github-pages Fri, 18 Dec 2015 00:00:00 -0500 Jekyll and GitHub Pages is a combination that’s hard to beat. Free and lightweight, you can use this combination to host a static website or blog. Unlike most other solutions, you simply generate your content and host it statically. This means not only a fast site, but one that is immune from many security issues that other blog software encounters. The problem, of course, is that Jekyll is a bit technical to use and to get set up. Once it’s set up, though, it’s quite easy to create content.

The majority of the instructions below are one-time setup items. When you’re simply wanting to update content or add a new blog post, you only need to follow the directions under the Adding New Content section. More detailed instructions on using Jekyll can be found in the excellent documentation on the Jekyll home page.


I’ll be using a Mac for this, though the instructions are very similar for a Linux machine. To get started, you’ll need:

  • A domain name - Having your own domain name keeps your content indepedent of the underlying blogging platform.
  • A free GitHub account
  • Plain Text editor of choice (TextMate, Sublime Text, TextWrangler, BBEdit, etc.)
  • Understanding of Markdown syntax - GitHub has a nice Markdown Basics page

GitHub Setup

Once you have set up your GitHub account, create a new repository. (If you want to keep your content private, you can pay an inexpensive monthly fee.) You can name the repository anything you like, though I suggest naming it after your domain name. This is a one-time action.

Repository Creation

GitHub repository creationGitHub repository creation

Check the box to initialize the repository with a README file, choose Jekyll from the .gitignore dropdown, and add a license if desired.

Set default branch

After your repository has been created, you will want to create a new branch and set it as the default.

On the left-hand side of the screen, click the dropdown that says Branch: master, type in gh-pages, and click Create branch: gh-pages to create the branch.

Creating the gh-pages branchCreating the gh-pages branch

Now, set your newly created gh-pages branch as the default branch. Click Settings, Branches, and choose gh-pages from the dropdown under the Default branch heading. Click Update and click through the Are you sure? notification.

Set default branchSet default branch

Installing GitHub Desktop

Download GitHub Desktop and install it on your Mac. We will use this to keep a local copy of your site on your computer and synchronize changes back to GitHub with it. After installation, open GitHub Desktop, log into your GitHub account, and add the repository you created previously.

Choose File, Clone Repository, select your repository, and click the Clone button. Choose a location to store the clone. (I normally choose the Sites folder on my Mac.) This will create a subdirectory named after your repository in the folder you chose.

Installing Jekyll

There are several ways that you can install Jekyll locally. The following approach will ensure that you’re consistent with the version of Jekyll and the plugins GitHub Pages uses.

Step 1: Homebrew (for Mac only)

If you’re on a Mac, the first thing to do is to install Homebrew. Follow the instructions on the homepage. You may additionally be prompted to install OS X Command-Line Tools first.

Step 2: Ruby and GitHub Pages gems

To install Jekyll, run the following commands from the Terminal:

  • brew install ruby
  • gem install github-pages

This installs an updated version of Ruby into /usr/local/bin, as well as Jekyll and all plugins used by GitHub for GitHub Pages. More details can be found under the Installing Jekyll heading on the Using Jekyll with GitHub Pages page.

(Note: This page also mentions how to keep Jekyll updated.)

Jekyll Theme

You may choose to follow the instructions to create an empty Jekyll site on the aforementioned instructions. However, many people opt to start with a theme, which has the basic structure of a Jekyll site. There are many places to find a Jekyll theme. Some examples include:

We will use the main Poole theme. Simply choose the Download button on the right-hand side of the page. Extract the contents and place them in your local copy of your repository. Changes you need to make vary per theme, as there is no actual standard on theme creation or configuration.

Modify the _config.yml configuration file and change a few settings. For example, let’s change the follow sections:

# Setup
title:               My Example Blog
tagline:             Just another hello world.
url:                 http://www.example.com
paginate:            1
baseurl:             ""

# About/contact
  name:              Your Namehere
  url:               https://twitter.com/example
  email:             example@example.com

Additional changes may need to be made to the theme pages, which are in the _includes and _layouts folders. Additional files like about.md and index.html may need modifications too.

Previewing Content Locally

Now that the basic setup is complete, run Jekyll locally to test the site configuration and see how the site looks. Being able to preview posts locally prior to generation is useful, and something you can do when working on drafts. To run Jekyll, open up a Terminal window, navigate to the main directory for you site by typing something similar to cd Sites/www.example.com, and type jekyll serve. You’ll see something similar to the content below:

Configuration file: /Users/trhall/Sites/www.example.com/_config.yml
            Source: /Users/trhall/Sites/www.example.com
       Destination: /Users/trhall/Sites/www.example.com/_site
 Auto-regeneration: enabled for '/Users/trhall/Sites/www.example.com'
Configuration file: /Users/trhall/Sites/www.example.com/_config.yml
    Server address:
  Server running... press ctrl-c to stop.

Now, go to your browser and navigate to http://localhost:4000/ and you’ll see the homepage for the site if all went well.

Local browser preview of the websiteLocal browser preview of the website

If you want to make additional changes to posts or the homepage, simply make changes and save them. The changes will apply automatically when you refresh the site in your browser. Note: If you want to make changes to your configuration file, you’ll have to stop and restart Jekyll for those changes to take effect. Simply go back to the Terminal window and type Ctrl-C to stop Jekyll and type jekyll serve again.

You may want to remove the sample pages in the _posts directory and add your own first entry. Files are named using a YYYY-MM-DD-your-title-here.md convention. Drafts can be created by using your-title-here.md without YYYY-MM-DD on the front.

Code and browser previews side by sideCode and browser previews side by side

Configuring Your Domain Name

In order to allow GitHub Pages to serve up your site from your own domain name, you need to create a CNAME file (all caps) to GitHub Pages to use your domain name instead of their default github.io name. In the top level of your repository directory, create a file named CNAME (all caps, no file extension) with the name of your site as the contents of the file. For example: www.example.com

You also must configure a CNAME entry with your domain registrar. Have it point youruserid.github.io, where youruserid is the user ID registered with GitHub.

Deploying the Site

GitHub Desktop to Commit and Sync changesGitHub Desktop to Commit and Sync changes

Now that you are sure that the site is set up to your liking, you are ready to deploy the site. Since you’re done testing locally, stop Jekyll in the Terminal by typing Ctrl-C. Then, go to GitHub Desktop under the Uncommitted Changes tab, type in a summary (and optional description) and click the Commit and Sync gh-pages button. If everything went well, you should see your blog online via the CNAME domain entry you created.

Deployed Site on GitHub PagesDeployed Site on GitHub Pages

Adding New Content

To add new content, simply create a new post. Preview locally by running jekyll serve. When you’re ready to publish a post, use GitHub Desktop to Commit and Sync and view your new content!

Quick Fixes via GitHub

If you’re not near a computer that you have Jekyll installed on and simply need to make a quick change to a page or if you want to type a post directly into a web browser editor, you can do the basics using the GitHub website interface. This interface is limited to adding or editing text content, so you can’t easily upload images. But it works in a pinch.

Simply navgiate to the repository on GitHub, navigate to the _posts directory, then either:

  • Edit Existing: Choose an existing file and click the Edit (pencil) icon
  • Create New: Click the New File button

Alternative Ways to Add Content

Web: Prose.io

While editing directly in GitHub works, it isn’t ideal. However, Prose.io to the rescue! Prose.io was created by Development Seed to more easily edit Jekyll sites on GitHub Pages. Fun Fact: Prose was used to create and maintain the HealthCare.gov website.

You can authorize Prose to access your GitHub account and then you can edit posts or create new files (including uploading images) via a web-based editor. It even has the ability to preview content and can work with drafts or publish a page for you. Did I mention it’s free?

Prose.io editing a blog postProse.io editing a blog post

iOS: Working Copy

Sometimes you need to edit content on the go. With Working Copy, you can directly view and edit content from GitHub. Content can be edited directly in the application or sent to some well-known editors on iOS, including Editorial and Byword. Once you sync back to GitHub, your changes will automatically be picked up.

Working Copy on iOSWorking Copy on iOS

<![CDATA[ Using Let's Encrypt for Automated SSL Certificates ]]> https://www.trhall.org/using-lets-encrypt-for-automated-ssl-certificates https://www.trhall.org/using-lets-encrypt-for-automated-ssl-certificates Sun, 13 Dec 2015 00:00:00 -0500 As soon as I heard about Let’s Encrypt, I knew that I had to try it out. Being able to generate and renew SSL certificates for free using automation is a noble cause. Having the Internet encrypted by default is important. As of 2015-12-03, Let’s Encrypt is in public beta, which means anyone can now create SSL certificates for free. Currently, it’s still quite technical to use, but companies will doubtless provide more automated integration to generate and use these certificates.

I won’t go into too much detail on how to install the official letsencrypt-auto client, as it is still in beta and is subject to change. The How It Works page gives some basic information. I’ll assume that you’re installing this on a Linux server and using Nginx web server, running under the user ID myuserid. If you’d prefer to use Apache web server, it has integrated functionality to install the generated SSL certificates. Full details are in the official documentation site.

cd $HOME/bin/
git clone https://github.com/letsencrypt/letsencrypt

As the letsencrypt-auto tool is being actively modified during the public beta, you’ll want to keep updated with the latest version. To update, simply run the following command to update:

cd $HOME/bin/letsencrypt
git pull

Configuring Nginx for Let’s Encrypt Challenge

The following is an example of a configuration file for Nginx. Simply add the listen 443 ssl; and include includes/letsencrypt-ssl; lines:

server {
    listen 80;
    listen 443 ssl;

    root /var/www/www.example.com;
    index index.html index.xml;

    server_name www.example.com;

    # Include SSL configuration
    include includes/letsencrypt-ssl;

Details that can be reused for each site’s SSL certificate are stored in a common file, includes/letsencrypt-ssl. Contents of this file are:

ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

# Let's Encrypt webroot authentication
location '/.well-known/acme-challenge' {
    default_type "text/plain";
    root /tmp/letsencrypt-auto;

Generating a certificate

In this example, I’ll add two domain names (www.example.com and wiki.example.com) to a single certificate using Let’s Encrypt’s SNI support. We’ll use this certificate with Nginx. This is based on the instructions in forum post. The latest version of these instructions from renchap are available in this GitHub Gist.

$HOME/bin/letsencrypt/letsencrypt-auto certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=/tmp/letsencrypt-auto -d www.example.com -d wiki.example.com

This installs the certificate and account information for Let’s Encrypt in the /etc/letsencrypt/ directory. Restart nginx using something like sudo service nginx reload to allow the settings to take effect.

Automating Certificate Renewal

We can run a command similar to the original one used to generate the certificate. We can run this every month to keep the certificate upated. The following shell script ($HOME/bin/letsencrypt_renew.sh) will be what we run monthly via cron:


/home/myuserid/bin/letsencrypt/letsencrypt-auto --renew certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=/tmp/letsencrypt-auto -d www.example.com -d wiki.example.com

sudo service nginx reload

Now, let’s add this to our crontab (using crontab -e to modify the crontab):

0 0 1 * * /home/myuserid/bin/letsencrypt_renew.sh

Now, part of the letsencrypt-auto command requires running via sudo. Since we want this to run automatically via cron, we don’t want to be prompted for a password. Update the sudoers file to allow these commands to run without a password. Edit the sudoers file using the visudo command and add the folowing lines:

# Run without password
myuserid  ALL = NOPASSWD: /home/myuserid/.local/share/letsencrypt/bin/letsencrypt, /usr/sbin/service

This will allow the letsencrypt binary and the service command (used to restart nginx) to run automatically.

Now, your SSL certificates should be renewed every month, automatically!

<![CDATA[ Configuring Dynamic DNS with Google Domains ]]> https://www.trhall.org/configuring-dynamic-dns-with-google-domains https://www.trhall.org/configuring-dynamic-dns-with-google-domains Tue, 08 Dec 2015 00:00:00 -0500 One of the nice features of Google Domains is that they also support Dynamic DNS. While there are other services that support Dynamic DNS, why not take advantage of the free built-in functionality provided by Google Domains, using your own domain name? Let’s step through the process of setting up a Dynamic DNS entry with Google Domains, as well as updating the entry via ddclient on a computer within your home network.

This process is really straight forward. Simply follow the instructions in the help article about Dynamic DNS under the Setting up a Dynamic DNS synthetic record heading. Create a Dynamic DNS entry under the Synthetic Records heading. This creates a DNS A record that can be dynamically updated.

Dynamic DNS CredentialsDynamic DNS Credentials

Expand the triangle and click View Credentials to see the generated username and password. This will be used in the next section.

Installing ddclient

Some routers have the ability to update Dynamic DNS entries directly within the router interface. In my case, I’m using an Apple Airport Extreme, so I need to install a client program on one of the computers in my network. In this case, I’ll use ddclient via Homebrew:

sudo brew install ddclient

Configuring ddclient

Create a configuration file /usr/local/etc/ddclient/ddclient.conf, adding details that Google Domains generated above.

use=cmd, cmd=/Users/example/bin/get_external_ip.sh

In my case, since I’m using a computer connected via a router, I need to get my external IP address. This article on OS X Daily was quite helpful to determine a quick dig command to accomplish this.

Create the script used in the cmd section above, in this case, get_external_ip.sh:


dig +short myip.opendns.com @resolver1.opendns.com

Testing ddclient

First, let’s test ddclient to make sure it works:

sudo /usr/local/opt/ddclient/sbin/ddclient -verbose

If things worked, then the entry in Google Domains will now show your IP address.

Running ddclient regularly

On my Mac, I would also like to run ddclient regularly. This will keep my DNS entry updated in the event that my external IP address changes. You could accomplish this via cron, but we’ll use the built-in Mac functionality (launchctl). Homebrew already comes with the .plist file needed, it just needs to be activated.

sudo cp -fv /usr/local/opt/ddclient/homebrew.mxcl.ddclient.plist /Library/LaunchDaemons
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.ddclient.plist

This will run every 300 seconds (5 minutes) and ensure that my IP is kept updated.

<![CDATA[ Registering an Internationalized Domain Name (IDN) ]]> https://www.trhall.org/registering-an-internationalized-domain-name-idn https://www.trhall.org/registering-an-internationalized-domain-name-idn Thu, 03 Dec 2015 00:00:00 -0500 So I finally got around to registering my Chinese name, 賀立德, as an Internationalized Domain Name (IDN). While Google Domains doesn’t state explicitly that they support them, they do. Other popular registrars like Hover do as well.

Doing this is much easier than one would think. Some registrars support typing in native scripts like 中文 (Chinese), where others require that you convert to Punycode when searching for domains to register. Punycode is an ASCII representation of native scripts, which is how IDNs are stored internally. Try searching first using the native script. If that does not work, then convert to Punycode first and then search.

Searching for an IDN on Google DomainsSearching for an IDN on Google Domains

Google Domains, for example, allows direct entry in a native script. In this example, I searched in traditional Chinese, and Google found the domain name.

Searching for an IDN on HoverSearching for an IDN on Hover

Hover, on the other hand, failed when searching in a native script. So, I converted the domain to Punycode and then the search succeeded.

Converting to Punycode

How did I convert to Punycode? Simple. I used Punycoder. Punycoder allows you to enter text and it converts to Punycode. Simply copy the resulting Punycode and use it!

Converting to Punycode using PunycoderConverting to Punycode using Punycoder


Now that I’ve successfully registered my IDN via Google Domains, I am able to type in my IDN URL and visit my domain. I registered both the Traditional (賀立德) and Simplified (贺立德) Chinese versions of my name.

<![CDATA[ Long Time Coming ]]> https://www.trhall.org/long-time-coming https://www.trhall.org/long-time-coming Sun, 12 Oct 2014 00:00:00 -0400 After years of changing things up and not being satisfied, I decided it was time to just go ahead and launch the site. Finally found a theme that I really like, and am running the site on Jekyll. I think that static site generators are the right way to go for most websites, and like both Jekyll and Pelican. Ultimately, the automated deployment to GitHub Pages is what convinced me to go with Jekyll over Pelican.