Discourse server failing to send email to the initial registered user


(Nikolaj Ivancic) #1

I am trying to find out why is my just instantiated Discourse server failing to send email to the initial registered user that the installation completed successfully. The email address I am trying to receive the message about successful Discourse installatation is receiving emails from different sources just fine. so it must be that Discourse server’s email configuration that is defined as

  DISCOURSE_SMTP_ADDRESS: smtp.elasticemail.com
  DISCOURSE_SMTP_PORT: 2525
  DISCOURSE_SMTP_USER_NAME: nik@aureliatools.com
  DISCOURSE_SMTP_PASSWORD: "c2bab563-b7fb-428c-bbfa-f97853e2c03b"

Note that I changed the password to preserve privacy and that the above settings are taken from my elasticmail account.

Once Discourse server installation task invoked by ./discourse-setup successfully finishes, I can access the server via browser, at which time, I need to specify the email address where the server will send the “verification email”.

That email never arrives.

Since I have only (PuTTY) console attached to my droplet, I do not have good ideas how to debug this.


(Jay Pfaffman) #2

It turns out, this question has been asked before. Please see Troubleshooting email on a new Discourse install.


(Nikolaj Ivancic) #3

@pfaffman - I looked at Troubleshooting email on a new Discourse install and believe that I tried all “tricks” there. As no absolute claims should be made, I will go through all that again (previously, I actually handled the case without using a preferred email provider and believed that my failure was caused by the email server I used is not willing to participate in application server to email server interactions; this indeed turned to be the case then)


(Nikolaj Ivancic) #4

@pfaffman - I got the command telnet smtp.elasticemail.com 2525 to execute flawlessly, so I do not believe it is network connection issue that I have a problem with.

There are no email related error messages in shared/standalone/log/rails/production.log. The one suspicious sections though is this (no idea why that would fail, but before going to DigitalOcean support, I thought it is better to mention it here)

Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack ["/var
/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:345:in `rescue in establish_connection'", "/var/ww
w/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:331:in `establish_connection'", "/var/www/discourse/v
endor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:101:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby
/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:293:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3
.3.3/lib/redis/client.rb:100:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:3
64:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:221:in `block in p
rocess'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:306:in `logging'", "/var/www/discou
rse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:220:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.3
.0/gems/redis-3.3.3/lib/redis/client.rb:134:in `block in call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3
.3.3/lib/redis/client.rb:280:in `with_socket_timeout'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis
/client.rb:133:in `call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/subscribe.rb:43:in `sub
scription'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/subscribe.rb:12:in `subscribe'", "/var/www
/discourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:2765:in `_subscription'", "/var/www/discourse/vendor/bundle/r
uby/2.3.0/gems/redis-3.3.3/lib/redis.rb:2143:in `block in subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/redis-
3.3.3/lib/redis.rb:58:in `block in synchronize'", "/usr/local/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'", "/var/www/di
scourse/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.3
.0/gems/redis-3.3.3/lib/redis.rb:2142:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/message_bus-2.0.5/lib/
message_bus/backends/redis.rb:302:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/message_bus-2.0.5/l
ib/message_bus.rb:513:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/message_bus-2.0.5/lib/me
ssage_bus.rb:461:in `block in new_subscriber_thread'"]
Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)

In summary: When loging into the newly created Discourse server with Chrome browser, and answering the initial form,
I get back

We sent an activation mail to admin@aureliatools.com. Please follow the instructions in the email to activate your account.

If it doesn't arrive, ensure you have set up email correctly for your Discourse and check your spam folder.

Nothing ever arrives to admin@aureliatools.com - nor are there any log entries on that server indicating that something was rejected. So, I believe that the installation script that installs Discourse did not send anything.

Lastly these are my current email settings:

  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  DISCOURSE_SMTP_ADDRESS: smtp.elasticemail.com
  DISCOURSE_SMTP_PORT: 2525
  DISCOURSE_SMTP_USER_NAME: nik@aureliatools.com
  DISCOURSE_SMTP_PASSWORD: c2bab563-b7fb-439c-bbfa-f97853e2c03b
  #DISCOURSE_SMTP_ENABLE_START_TLS: true

Is it possible that I am missing to define the mailbox on elasticmail.com (instead of nik@aureliatools.com)??


(Jeff Atwood) #5

Something’s wrong with your install if Redis is not working. I suggest going with Jay’s install service for $99 at https://www.literatecomputing.com/product/discourse-install/ – he will also set up email for you.


(Jay Pfaffman) #6

The redis problem is definitely a problem, but not related to sending mail. You followed discourse/INSTALL-cloud.md at master · discourse/discourse · GitHub?

Check the logs that elasticmail provides. Do they show that you connected and a message was delivered?

I don’t know what that means. Is nik@aureliatools.com the username that elasticemail gave you to connect to their SMTP server? That seems strange, but I’ve never used them. My best guess is that you are using the wrong credentials to connect to their mail server.


(Nikolaj Ivancic) #7

@codinghorror - I understand that your advice categorized me in the “bozo class”, but I am anything but that, quite seriously. Since I am completely devoted to (Aurelia) Open Source Community, meaning that I spend 60-70 hours a week on helping them, I do not want to spend the money to be able to work for free - that is a matter of principle.

I am only hoping that you will take my case (as a cofounder of Discourse) as an indication that installing Discourse on DigitalOcean can benefit from some improvements. I indeed love your product and if it was not written in one of the very few languages that I do not know, I would seriously offer you my help to improve this process.

Thanks for trying to help me

Sincerely

Nikolaj Ivancic


(Nikolaj Ivancic) #8

@pfaffman - my most current failure likely stems from using the nano editor in the Digital Ocean console. I already observed that caused a script failure by “disrupting” the incredibly fragile Docker script (app.yml), so I had to fix that using vim, which I really dislike (was not able to paste the silly passwords being assigned to me by elasticemail).

I would think that the very primitive interface to DigitalOcean’s droplet management (their own console launched from the browser is worthless, so I had to use PuTTY - another archaic tool that might be wreaking havoc as well) is the main culprit that combined with extreme fragility of the .yml file processing, results with me spending three full days to get nowhere, knowing that if I could install this on my own physical server, it would take me less than one hour.


(Jay Pfaffman) #9

Having an extra space or tab totally break app.yml is hugely frustrating indeed.

You should be able to paste in the password using vim (if you can paste it using nano, anyway), by first entering insert mode (pressing i) then pasting. vim is definitely a tool with a 30 year old user interface. I don’t use it if I’m writing more than 100 words, but I almost always use it for sys admin tasks.

If you’re ready to throw in the towel, for $99 I’ll install it with Mailgun in a new Digital Ocean Droplet. If you really love elasticemail and/or the droplet you’ve created already, I’ll endeavor to make that work, but it’ll cost twice as much.


(Jeff Atwood) #10

Not at all, it’s just that advanced installation outside our setup script that asks the questions step by step is “sysadmin mode” and not everyone has, wants, or even needs that skillset.


(Nikolaj Ivancic) #11

@pfaffman thanks for the offer, which I will respectfully decline with the explanation I provided to @codinghorror a couple of hours ago. I can state categorically that I could significantly improve documents like discourse/INSTALL-cloud.md at master · discourse/discourse · GitHub to the point that it would have a negative impact on your business Jay :smile:.


(Jeff Atwood) #12

Unlikely, as that doc is the result of hundreds of hours of repeated installs and feedback. As I said, not everyone wants or needs the sysadmin skillset that you’re dipping into here, as you are off-script.


(Jay Pfaffman) #13

Wait. You know that you can just re-run ./discourse-setup to change the SMTP settings rather than use nano, or vim, right?

Your problem is almost certainly your SMTP settings and/or that you’ve not configured elasticmail.com correctly.


(Nikolaj Ivancic) #14

@codinghorror - with a lot of respect to you, I do claim to be able to dramatically improve the your documentation - as I have many thousands of hours doing top level technical writing, but that is not my point: just like someone who was mistreated by the servers in the restaurant and wants to pass that experience to the restaurant owner meaning only to help, I wanted to share with you my impression on the installation document that mislead me way to many times as well as the fragility of the tooling in the context of DO hosting provider. I also want to state for the record that I am extremely impressed with your product (Discourse) and that should not be taken lightly as I dealt with most of the products that hope that they compete with you.

I managed to resolve all issues and got my server instance to work - and will drop it (at DO) as I found out that Aurelia’s Community is already taken care of. I made just one error (not configure the account at elasticemail, being under the impression that the installation process uses its own account for that purpose - and that was a dumb error). Even that error could be prevented had that detail been explained with more details. The rest of my issues were all trivial - from getting a blacklisted IP form DigitalOcean to inadvertently damaged .yml file.

In summary, I am leaving with great appreciation for all folks that were so ready to help. That includes @pfaffman as well (by the way, I happen to have a PhD in math and the equivalent in Computer Science just like Jay does :smirk:)

Almost forgot to comment Jay’s sentence You know that you can just re-run ./discourse-setup to change the SMTP settings rather than use nano, or vim, right?.

Yes, learned that very early in the game and also learned not to do that because the discourse-setup would add double quotes surrouding the password set that way and butcher my attempt to define more than a single user - feature that is clearly listed in this document.

Thanks and regards again


(Jeff Atwood) #15

Ok, if you have suggestions to improve the instructions, send a pull request on the content through github.com


(Jay Pfaffman) #16

Can you explain the password quote problem a bit more?

You’re saying that you cannot have multiple admin email addresses?


Mailgun is not loving your login or password
(Drew Ridley) #17

Correct. You cannot have multiple admin email addresses upon initial setup. You can however, have multiple email addresses. Upon initial setup, you can only select a single one.