Getting dev instance to send email?


(hamburglar) #1

Is there any trick to getting a dev instance to send email? I managed to get a copy set up and running, but when I sign up, the email never gets sent. I have sendmail installed and I don’t see any errors in the app log, but I also don’t see any activity in the system mail log. Any hints as to what to look at?


(Deliverator) #2

Assuming your mailserver is correctly configured it’s probably going to be listening on port 25. Discourse’s default in development looks to be 1025. So I’d suggest bopping into config/environments/development.rb and changing 1025 to 25.

That being said, I’ve already done this and am still puzzling out why mail sending remains broken for me.

I can send mail via the command line, and by telnet’ing to port 25 of localhost and having a valid SMTP conversation.

Sending from within Discourse is silently failing (nothing in app log, app error log, or exim main and reject log) whether I tell it to use the sendmail binary or stmp on port 25.

About to take a break, but my next approach is going to be digging into actionmailer settings.


(Jeff Atwood) #3

Be sure to check

/admin/email_logs

in your instance as well… there is a Send Test Email button there with some important deliverability tips, too.


(hamburglar) #4

Heh, well that is a bit of a catch-22 since I didn’t have an activated account, let alone an admin one. Would be handy for dev if you dumped the email or maybe the activation link out to the log when creating a new user, just in case of lacking email setup.

I worked around it by poking my trust_level and admin fields in the users table and I’m in business. /admin/email_logs doesn’t tell me anything at all, and trying to send an email from there just says “sent!” and nothing ever happens. I even tried strace and tcpdump to see if I saw anybody attempting to open a port 25 socket (I did change the config from 1025 to 25), but no dice. Oh well, since I can manually validate accounts, it’s no big deal for now. For the record, though, this seems wrong:

discourse_development=# select * from email_logs;
 id | to_address | email_type | user_id | created_at | updated_at 
----+------------+------------+---------+------------+------------
(0 rows)

I’ve seen some complaints of slowness, but other than initial startup taking 30 seconds or so, it seems pretty snappy running on my lowest-tier Rackspace Cloud VM.


(Neil Lalonde) #5

We’ve been using Mailcatcher to avoid the whole issue of actually sending emails. Check it out:

If you’re using the vagrant image, ssh into it and run this command:

mailcatcher --http-ip 0.0.0.0

Then in a browser, go to http://localhost:4080

Sent emails will be received by mailcatcher and shown in its web ui.


(hamburglar) #6

Oh, mailcatcher is a brilliant idea. That will come in handy for my real dev work. Thanks!


(Sam Saffron) #7

Let’s make sure this is somewhere in DEVELOPMENT.md


(Dave H) #8

I had the same issue, but realized I could log on without activating, then just set admin=true manually.


(hamburglar) #9

How did you log on without validating? I got an invalid user error until I manually validated by fiddling with the db.


(Dave H) #10

Great question! Perhaps I set the admin flag before, and that’s what did it. I’ll test on a new install later today.


(Kuba) #11

For me, the default installation lets me login and post even without email activation. Just register, go back, login and voila. Probably a bug.


(Neil Lalonde) #12

Done!


#13

I think the expected behavior is just not posting when you’re not validated, though I may be wrong.


(Deliverator) #14

Tracked down my problem with mail not working- wasn’t running sidekiq.

bundle exec sidekiq


(Neil Lalonde) #15

I just fixed this. Shouldn’t be able to sign in until email is confirmed.


(Neil Lalonde) #16

[quote=“Deliverator, post:14, topic:2507, full:true”]Tracked down my problem with mail not working- wasn’t running sidekiq.

bundle exec sidekiq[/quote]

I added this to instructions in DEVELOPMENT.md. Thanks for reporting it.


(Neil Lalonde) #19

You might not want your thins and sidekiq process running on the same server. It’s up to you where and how sidekiq is run.

We use bluepill to start processes and monitor them. It’s a good idea to use a solution like that to start up all the things (thins, sidekiq, clockwork), and handle when they die.


(andrew) #20

This was my issue as well. For reference, you can run ‘bundle exec sidekiq -d -L path/to/logfile’ to run it as a daemonized process (path/to/logfile can be anywhere you want to store the sidekiq logs, for instance ‘log/sidekiq.log’).


(bnolan) #21

I just looked up the email_token from the email_tokens table and went to:

localhost:5000/users/activate-account/:email_token

Doneburgers.


#22

@neil: I couldn’t get mailcatcher to catch Discourse emails.

First, mailcatcher was not installed properly in my vagrant image. I had to reinstall it before I could run it (source here):

$ gem uninstall mailcatcher
$ rvm default@mailcatcher --create do gem install mailcatcher
$ rvm wrapper default@mailcatcher --no-prefix mailcatcher catchmail

Then only could I run mailcatcher --http-ip 0.0.0.0 and see the GUI at http://localhost:4080. But no email was caught when sending the email to activate the admin account.

So, for now, I have activated the admin account like this (source here):

bundle exec rails c
u = User.find_by_id 1
u.activate
u.grant_admin!
exit