2 min read

Typo-people of the world unite!

I've set the blog up with ngingx over a week ago now, ever since I've had issues with the Subscriptions & Ghost Portal in general. Basically what was happening is—the admin portal was calling for resources to allow member registering & logging in. For some reason the website was working fine, with the SSL setup, but the admin panel was not. It was constantly calling for resources sitting on http://jugglingjsons.dev instead of https://jugglingjsons.dev.

I've been banging my head against the wall for a while before I resorted to going through every line of configuration from bottom up!

Battle plan was:

  1. Check Nginx config
  2. Check Docker config
  3. Check Ghost container config
  4. Look for help

It's all sitting behind a ngingx which I must have restarted a thousand times by now. It's a relatively simple configuration and everything was fine there! Below is roughly what I found there:

server {
    listen 80;
    server_name jugglingjsons.com;
    access_log /var/log/nginx/jugglingjsons.com.log;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header HOST $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;
    }
}

server {
    server_name jugglingjsons.com;
    listen 443 ssl;
    location / {
            proxy_pass      http://127.0.0.1:2368;
            proxy_set_header    X-Real-IP $remote_addr;
            proxy_set_header    Host      $http_host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    ssl_certificate /etc/letsencrypt/live/jugglingjsons.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/jugglingjsons.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = www.jugglingjsons.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    if ($host = jugglingjsons.dev) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
}

Since it was clearly working fine when I pinged all the addresses, including the SSL redirects, I had to look elsewhere, following the plan devised before I directed my efforts towards the docker configuration. Here is where I've found it.:

-e url="http://jugglingjsons.dev"
#instead of
-e url="https://jugglingjsons.dev"

That was enough to cause issues for a couple of days. Mostly because I forgot I've put some settings / variables onto the docker container itself. I have another config file for Ghost itself and for a while I thought the software was caching the configuration somewhere, as the config looked somewhat similar to this:

{
  "url": "https://jugglingjsons.dev",
  "server": {
    "port": 2368,
    "host": "0.0.0.0"
  },
  "database": {
    "client": "sqlite3",
    "connection": {
      "filename": "/var/lib/ghost/content/data/ghost.db"
    }
  },
  "mail": {
		...
    }
  },
  "logging": {
    "transports": [
      "file",
      "stdout"
    ]
  },
  "process": "systemd",
  "paths": {
    "contentPath": "/var/lib/ghost/content"
  }
}

I remember briefly thinking about setting the whole thing up late at night. Believe it or not, but I was sure the application config would have taken precedence over the process.env variable that the docker configuration was setting.

Lesson learnt:

Don't assume, ask first. It will save you a lot of drama.

Off to configuring cert renewal!