Install Hugo↑

We just grab the latest binary for a 64-bit Linux from GitHub, unpack it, and store it somewhere on the $PATH.

wget https://github.com/gohugoio/hugo/releases/download/v0.70.0/hugo_0.70.0_Linux-64bit.tar.gz
tar xvf hugo_0.70.0_Linux-64bit.tar.gz

We can then set up a page:

hugo new site chollinger-blog

After some small edits to the config.toml, we should be good to go and only need content.

baseURL = "https://chollinger.com/blog"
languageCode = "en-us"
title = "Christian Hollinger"
theme = "ananke"

Exporting all old posts↑

I want to export all old blog posts to Markdown. There’s a great little tool by lonekorean on GitHub.

All we need is an export of WordPress and run:

git clone https://github.com/lonekorean/wordpress-export-to-markdown
cd wordpress-export-to-markdown
npm install
node index.js

After that, we can copy the generated files to the posts directory.

There are other tools available here, but since I’ve already customized WordPress quite a bit, the above export was a possible route. Your mileage may wary.

Testing↑

Start a dev server that automatically refreshes once we save a file:

Pretty? Well..

Themes↑

We also need a real theme for the page.

My personal decision criteria for a theme were the following:

• No external dependencies to CDNs, googleapis, Google Analytics, trackers…
• Simplistic interface, without omitting information
• Fast load times even on slow connections

I chose hugo-ink by knadh, but customized it quite heavily to match some of my requirements. This resulted in a fork called ink-free.

Adjustments can be easily made using fairly standard HTML (w/ Hugo’s injections) and CSS, which I found easy to figure out, despite being anything but a Web Dev. :)

The changes made to that theme were the following:

• Removed all references to Google’s font-CDN
• Removed Analytics code, even if it was controlled by a variable
• Modified the CSS to
  • Order all tags inline, as opposed to as a list
  • Change the background color for Syntax Highlighting, otherwise we’re looking at grey code on a grey background
  • Added some classes for a Back button
• Added a Back button to all posts
• Added a TOC, controlled by a variable, to all posts
• Added a word count, tags, and an approximate read time to the overview
• Added very serious, random messages at the end of the posts

Most of it was simple HTML and CSS updates, like this update for the Back button:

.tag-li {
    display:inline !important;
}
.back {
    padding-top: 1em;
    font-size: 1em;
}

The last part with the random messages was interesting, as Hugo / the underlying go Syntax allows you to pipe commands:

<div class="back">
  {{ if isset .Site.Params "footers" }}
    {{ if ne .Type "page" }}
      Next time, we'll talk about <i>"{{ range .Site.Params.footers | shuffle | first 1 }}{{ . }}"</i>{{ end }}
    {{ end }}
  {{ end }}
</div>

And I am reasonably happy with the result:

Feel free to check out the theme’s repository here: https://github.com/chollinger93/hugo-ink

Adjusting exported blog posts↑

Due to my rather interesting WordPress configuration, the exported posts from above need some help.

The issues I’ve found where the following:

• GitHub Gits are not rendered
• Internal Syntax Formatting caused everything to be escaped with \, breaking code
• Headlines are missing
• Tags are missing
• Descriptions are missing

<script src="https://gist.github.com/chollinger93/8dcc79ab16daf5fcdda3df1a4ccc183a.js"></script>

{{</* gist chollinger93 8dcc79ab16daf5fcdda3df1a4ccc183a */>}}

grep "gist.github.com" *.md | while read -r line ; do
    guser=$(echo "${line}" | cut -d'/' -f4)
    gist=$(echo "${line}" | cut -d'/' -f5 | sed -E 's/(\.js).+//g')
    echo "$gist"
    repl="{{/* gist "${guser}" "${gist}" */>}}"
    # Get line number
    ln=$(grep -n "$line" *.md | cut -d : -f 1)
    # Replace
    echo "Replace line $ln with ${repl}"
    sed -Ei "$ln s#.*#${repl}#g" *.md
done

Shortcuts↑

I’ve also added a Visual Studio Code shortcut in keybindings.json to insert Hugo’s Syntax Highlighter blocks:

[
    {
        "key": "ctrl+1",
        "command": "editor.action.insertSnippet",
        "when": "editorTextFocus",
        "args": {
            "snippet": "{< highlight bash \"linenos=table\" >}"
        }
    },
    {
        "key": "ctrl+2",
        "command": "editor.action.insertSnippet",
        "when": "editorTextFocus",
        "args": {
            "snippet": "{< / highlight >}"
        }
    }
]

Permalinks↑

In order to avoid breaking links, and hence any bit of SEO we might have, we need to make sure that either all posts follow the same naming schema - they do in my case - or add a setting in config.toml:

[permalinks]
  posts = "/:year/:month/:title"

In order to ensure this is indeed a 100% match, I wrote this horrible little go script to compare both the local (after hugo build) and remote RSS feeds:

package main
import (
  "os"
  "fmt"
  "github.com/mmcdole/gofeed"
)
func mapToUrl(feed *gofeed.Feed) map[string]string {
  output := map[string]string{}
  for _, post := range feed.Items {
    output[post.Link] = post.Title
  }
  return output
}
func readFeed(path string) *gofeed.Feed {
  fp := gofeed.NewParser()
  //remtoteFeed, _ := fpR.ParseURL("https://chollinger.com/blog/feed")
  file, _ := os.Open(path)
  defer file.Close()
  feed, _ := fp.Parse(file)
  return feed
}
func compareUrls(local, remote map[string]string) bool {
  allFound := true
  for k, _ := range local {
    fmt.Println(k)
    if title, ok := remote[k]; ok {
      fmt.Printf("Found %s\n", title)
    } else {
      fmt.Printf("Could not find %s locally, url: %s\n", title, k)
      allFound = false
    }
  }
  return allFound
}
func main() {
  // Remote
  remoteFeed := readFeed("./wordpress.xml")
  remote := mapToUrl(remoteFeed)
  // Local
  localFeed := readFeed("../public/index.xml")
  local := mapToUrl(localFeed)
  // Compare
  fmt.Println(compareUrls(local, remote))
}

Which did find some errors.

christian @ pop-os ➜  sbin git:(master) ✗  go run check_rss.go | grep "Could not"
Could not find  locally, url: https://chollinger.com/blog/2020/02/how-a-broken-memory-module-hid-in-plain-sight-and-how-i-blamed-the-linux-kernel-and-two-innocent-hard-drives/
Could not find  locally, url: https://chollinger.com/blog/2019/12/tensorflow-on-edge-building-a-smar-security-camera-with-a-raspberry-pi/

Which I was able to fix after deploying the first version of this article. Psst, don’t check the Git commits. :)

There were more adjustments that needed to be done - like re-adding videos - but for the most part, everything was working fine. I will spare you the tedious details.

workflow.yml↑

We’ll create a .github/workflows/workflow.yml file as such:

name: nginx
on:
  # Trigger the workflow on push or pull request,
  # but only for the master branch
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - name: Git checkout
        uses: actions/checkout@v2
      - name: Update theme
        # Update themes
        run: git submodule update --init --recursive
      - name: Setup hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "0.70.0"
      - name: Build
        run: hugo --minify -d blog
      - name: List status
        working-directory: ${{ github.workspace }}
        run: ls -larth blog
        continue-on-error: true
      - name: Install SSH key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.KEY }}
          name: id_rsa # optional
          known_hosts: ${{ secrets.KNOWN_HOSTS }}
      - name: sshpass
        run: sudo apt-get install -y sshpass
      - name: Deploy
        env:
          PASSWORD: ${{ secrets.PASSWORD }}
          USERNAME: ${{ secrets.USERNAME }}
          HOST: ${{ secrets.HOST }}
          TARGET_DIR: ${{ secrets.TARGET_DIR }}
        run: sshpass -p "$PASSWORD" scp -r blog/ "$USERNAME"@"$HOST":"$TARGET_DIR"

You can use some of the pre-configured SCP Actions instead of using bash. I had issues with those and since all Actions I’ve found either don’t support key passphrases or don’t supply proper debug logs, I gave up and used a bash action for deployment.

If you have any idea what “Exit code 1”, despite a successful connection on the server (as per syslosg anf auth.log), means, do let me know!

We’ll deploy via SCP, but only with a specific user that has restricted permissions.

Add the user:

useradd -m -d /home/github github
passwd github
su github

Make the user’s home owned by root:

sudo chown -R root:github /home/github
sudo chown github:github /home/github/.ssh
# + Any folders the deployment needs

Next, let’s compile rssh, an scp/sftp only shell.

wget http://prdownloads.sourceforge.net/rssh/rssh-2.3.4.tar.gz?download
tar -xvf rssh-2.3.4.tar.gz

And build:

# Build from source
./configure
make
sudo make install

We need to allow the user access, so we need to edit /usr/local/etc/rssh.conf as such:

user = "github:022:00001:/path/to/chroot"

This translates to:

• username: The username of the user for whom the entry provides options
• umask: The umask for this user, in octal, just as it would be specified to the shell
• access bits: Five binary digits, which indicate whether the user is allowed to use rsync, rdist, cvs, sftp, and scp, in that order. One means the command is allowed, zero means it is not.
• path: The directory to which this user should be chrooted (this is not a command, it is a directory name). See chroot_path above for complete details.

Please see the man page.

Especially setting up a chroot is a bit more involved than setting a single config file, so be advised to read through the appropriate man pages and CHROOT in the rssh source directory.

Make sure the users exists in AllowUsers under /etc/ssh/sshd_config

Edit the SSH config:

Ensure that the user is in the AllowUser directive. At this point, you might want to think about a separate rssh and ssh group.

And restart the SSH daemon:

Finally, change the user’s shell to /bin/rssh:

usermod -s /usr/bin/rssh github

Of course, at this point, you will also need to generate your ssh keys (use PEM for GitHub Actions, as I’m pretty sure the Ubuntu image used by their bash action uses a weird openssh version), set up whatever flow you need to actually get the HTML served (e.g., docker) but I will skip over that part in the interest of time.