Installation not working!

I’m trying to make a fresh install with the 1-click app from digital ocean.
It’s the third time I created it from the beginning and I’m experiencing the same issue.
Checking the dns, I see my domain pointing to the droplet’s ip, but discourse is not showing on my domain.

I run discourse-doctor and it stucks/ hangs before showing the “domain is served/not served” info.

Was there an update that could have introduced this behavior ?

1 Like

The one click install is not supported.

Please use the remarkably straightforward official install process.

Then if you have any issues with that, you can post those here and get support.


@merefield Just created a new droplet and run the installation as described on the official install. I’m still experiencing the exact same issue.

discourse-doctor hangs

and nothing is being served on my domain.

This is fully fresh with the official install. Can’t figure out what might be happening here. Any clues ?

1 Like

@merefield On the ./launcher logs app I see:

nginx: [emerg] cannot load certificate "/shared/ssl/": PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE)

not sure what that means though

1 Like

So I see it’s tryin to look at /shared/ssl but actually the ssl is at shared/standalone/ssl. How should I fix this ?

1 Like

The problem is usually that you don’t have DNS configured correctly or that it has not propagated. If you share your URL someone could check.

I often use to check

But if you have tried a bunch of times then you likely have exhausted the number of times that letsencrypt will send you a certificate. My guess is that is your current problem. I’m about 90% certain. You can “cheat” by following Setting up Let’s Encrypt with Multiple Domains, but it’s a more complicated setup and you couldn’t accomplish the simple one. Your best bet is probably to wait a few days and try again.

Not the problem. /shared/ssl is the path inside the container. shared/standalone/ssl is the path outside of the container.


@pfaffman Yeah, sound legit! Still I can’t create it, but I can create on another domain. Since the dns lookup shows that I’m connected to the correct server and all, I assume the case is what you described. I’ll wait some more days and try it again.
Thanks :metal:


@pfaffman Can you help me cheating? I had a look on setting it up with multiple domains, but I am not sure what you meant. Do you mean using the after_ssl hook somehow ?

1 Like

You’d just add any other domain. So if your forum is you’d add a dns record for pointing to your server and add it as described there. Since it would be a different certificate request, it’d let you request it.

1 Like

@pfaffman I’m using digital ocean. I added the as an A record, but it’s not accepted as a domain when setting up.

(WARNING: Port 443 of computer does not appear to be accessible)

Followed the instructions and rebuild, but still “The site can’t be reached”. :thinking:

For the rest of the conf, I just added

    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d"

inside hooks: on my app.yml file.

Or he can add one domain or subdomain using this. An easy way to get around it when you’ve hit a rate limit. But to avoid hitting the rate limits, it’s always best to use the test environment --dryrun. (Note that LetEncrypt is in the process of possibly renaming --dryrun to something easier for non-English speakers to recognize such as --test or --testrun. Most likely that won’t be until some time in January 2021 or later. They’re working on a complete rewrite of their guides as well. :slightly_smiling_face:

The recommended method for adding a new domain to an existing certificate is indeed to re-use the original command line, add the new domain with another -d flag, and add --expand to tell certbot not to create a new lineage (that would result in a new subdirectory in /etc/letsencrypt/live ).


The problem here is that you don’t know it’s a test until it’s too late. Also, it’s not clear even to me how to configure discourse to pull those certs in test mode.

That’s what I was trying to communicate.

1 Like

That’s one reason why they (at Lets Encrypt) are rewriting their guides… to make them more clear. Once you’re set up up getting a test (fake) certificate using the test environment, then one can run Cerbot in production mode and get their CA. After that, Discourse can be installed and it should grab the new (expanded) CA.


It’s not that. It’s that figuring out how to add a stanza to an app.yml to add that switch–however obvious it may be–is about 3X (or maybe 10X) as hard as installing Discourse. You’d need to edit app.yml and add a complicated thing and have all the spaces just right? Just wait a week or choose a new name.


@pfaffman I chose a new name as I described. One issue was that the should be a CNAME instead of A record.

It still doesn’t work though. I’ll give it some more time.

EDIT: For reference here is my app.yml:

  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml"

  - "80:80"   # http
  - "443:443" # https

  db_default_text_search_config: "pg_catalog.english"

  ## Set db_shared_buffers to a max of 25% of the total memory.
  ## will be set automatically by bootstrap based on detected RAM, or you can override
  db_shared_buffers: "256MB"

  ## can improve sorting performance, but adds memory usage per-connection
  #db_work_mem: "40MB"

  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

  LANG: en_US.UTF-8
  ## How many concurrent web requests are supported? Depends on memory and CPU cores.
  ## will be set automatically by bootstrap based on detected CPUs, or you can override

  ## TODO: The domain name this Discourse instance will respond to
  ## Required. Discourse will not work with a bare IP number.

  ## Uncomment if you want the container to be started with the same
  ## hostname (-h option) as specified above (default "$hostname-$config")

  ## TODO: List of comma delimited emails that will be made admin and developer
  ## on initial signup example ','

  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  # SMTP ADDRESS, username, and password are required
  # WARNING the char '#' in SMTP password can cause problems!
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

  ## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate

  ## The http or https CDN address for this Discourse instance (configured to pull)
  ## see for details

## The Docker container is stateless; all data is stored in /shared
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins go here
## see for details
    - exec:
        cd: $home/plugins
          - git clone
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d --expand"
1 Like

In the end a week passed and I was able to use my domain again. Probably I had some mistake in the config for making it work with the sub-domain, cause I’m pretty sure after reading at LetsEncrypt as well that this is the solution.

Thanks again @pfaffman and @JimPas for the help and the informative answers!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.