Iam looking to use this pkg to send emails in my django app:
https://github.com/sklarsa/django-sendgrid-v5
and I see the field: SENDGRID_ECHO_TO_STDOUT and the description says:
will echo to stdout or any other file-like object that is passed to the backend via the stream kwarg.
I literally do not get what this means. My understanding was that if I set this to True, the email WONT be delivered but will be saved as a file and will output 1 in the terminal ?
However when I see this:https://simpleit.rocks/python/django/adding-email-to-django-the-easiest-way/
I think the guy manages to send emails even when this flag is set to True? Is that correct?
Sorry if this is a daft quetsion - I just do not understand this flag.
Should the flag be set to True or False in production?
Related
I try to get return report from amazon, but my request is always cancelled. I have working request report using
'ReportType' => 'GET_MERCHANT_LISTINGS_DATA',
'ReportOptions' => 'ShowSalesChannel=true'
I modify it by changing ReportType and removing ReportOptions. MWS accept request by its always cancelled. I also try to find any working example of it on google but also without success. Meybe somone have working example of it? I can downolad report when I send request from amazon webpage. I suppose it require ReportOptions, but I dont know what to put in this place (I have only info ReportProcessingStatus CANCELLED). Normally I choose Day,Week,Month. I check on amazon docs but there isnt many informations https://docs.developer.amazonservices.com/en_US/reports/Reports_RequestReport.html
Any ideas?
My first post so please excuse any ignorance on my part. I have had great success with email automation using Exchangelib. I am curious to know if there is a configuration option to request a read or delivery receipt?
I have spent the last few days researching options but not having any luck.
You should be able to set the Message.is_read_receipt_requested boolean field. When set to True, you will get a read receipt when the is_read field of the received message is set to True, unless the receiver explicitly disabled sending read receipts.
Found the solution after searching, but leaving this here if somebody happens to run into similar kind of confusion. See resolution in the end.
I'm trying to figure out why AWS CloudWatch log service fails to understand the right timestamp for my log events. Currently all my events are being saved under Time 2017-01-01 no matter what the actual timestamp in the event is.
I'm feeding the log from syslog where docker is saving the logged events and I configured docker to put the timestamp in format:
170105/103242 (%y%m%d/%H%M%S)
I configured awslogs service with parameters:
datetime_format = %y%m%d/%H%M%S
I restarted the service and hit the server, but still when I go to CloudWatch and see the log entries, even entries that indeed start with timestamp 170105/103242 are actually saved as events that belong to date 2017-01-01 containing all events between 01-01 and 01-05
When I look at the awslogs.log I can see following lines:
2017-01-05 11:05:28,633 - cwlogs.push - INFO - 29223 - MainThread - Missing or invalid value for use_gzip_http_content_encoding config. Defaulting to using gzip encoding.
2017-01-05 11:05:28,633 - cwlogs.push - INFO - 29223 - MainThread - Using default logging configuration.
This makes me think that the configuration probably isn't actually reading/using the datetime_format but I don't understand why it decides to end up using default. I tried to put
use_gzip_http_content_encoding = true
under general settings, but it doesn't change the errors.
I am running out of ideas - has anyone managed to configure awslogger in a way where the datetime_format is actually used correctly?
Edit:
I'm currently hacking more console logs to local python2.7 push.py to see what is going on :)
RESOLVED:
Ok, problem was that I came into this project after the initial setup had been created and I had the impression that the logger was configured to use the .conf file in location:
/etc/awslogs/awslogs.conf
that was dynamically populated.
The environment had a script that gave this location to awslogs-agent-setup.py which tried to make the agent understand that configuration should be read from here.
However this script didn't actually do what it was supposed to do and when the service started, it actually read the config from
/var/awslogs/etc/awslogs.conf
Which contained the default values.
So the actual resolution was to change the datetime_format parameter in the default config and forget about the config I thought the service was using.
Add logging to /var/awslogs/lib/python2.7/site-packages/cwlogs/push.py and see how the actual config parameters are interpreted.
You will probably find out that the service is actually using configuration file at default location:
/var/awslogs/etc/awslogs.conf
and hence you have to edit configuration values there for them to be actually read.
I am using a Logstash + Elasticsearch stack to aggregate logs from a few interrelated apps.
I am trying to get Monit to alert whenever the word 'ERROR' is returned as part of an Elasticsearch REST query from Monit, but the 'content' regex check does not seem to be working for me. (I am sending email and SMS alerts from Monit via M/Monit.)
I know my Monit and M/Monit instances are configured properly because I can get alerts for server pings and file checksum changes, etc. just fine.
My Monit Elasticsearch HTTP query looks like this:
check host elasticsearch_error with address 12.34.56.789
if failed
url http://12.34.56.789:9200/_search?q=severity%3AERROR%20AND%20timestamp%3A>now-2d
and content = "ERROR"
then alert
BTW, %20 escapes 'space', %3A escapes ':'
My logstash only has error log entries that are between one and two days old. i.e., when I run
http://12.34.56.789:9200/_search?q=severity%3AERROR%20AND%20timestamp%3A>now-2d
in the browser, I see errors (with the word 'ERROR') in the response body, but when I run
http://12.34.56.789:9200/_search?q=severity%3AERROR%20AND%20timestamp%3A>now-1d
I do not. (Note the one-day difference.) This is expected behavior. Note: my response body is a JSON with the "ERROR" string in a child element a few levels down. I don't know if this affects how Monit processes the regex.
When I run the check as above I see
'elasticsearch_error' failed protocol test [HTTP] at
INET[12.34.56.789:9200/_search
q=severity%3AERROR%20AND%20timestamp%3A>now-2d]
via TCP -- HTTP error: Regular expression doesn't match:
regexec() failed to match
in the log. Good. Content == "ERROR" is true. I can alert from this (even though I find the Connection failed message in the Monit browser dashboard a little irritating...should be something like Regex failure.)
The Problem
When I 'monit reload' and run the check with
url http://12.34.56.789:9200/_search?q=severity%3AERROR%20AND%20timestamp%3A>now-1d
I STILL get the regexec() failed to match error as above. Note, I return no "ERROR" string in the response body. Content == "ERROR" is false. Why does this check fail? Any light shed on this issue will be appreciated!
The Answer
Turns out this problem is about URL encoding for the Elasticsearch query.
I used url http://12.34.56.789:9200/_search?q=severity:ERROR×tamp:>now-36d in the check to get Monit to make a request that looks like 12.34.56.789:9200/_search?q=severity:ERROR×tamp:%3Enow-36d. Note change in encoding. This seems to work.
The actual URL used by monit can be seen by starting monit in debug mode using monit -vI.
Side Question
The 'content' object seems to respect '=' and '==' and '!='. '=' is referenced in the documentation, but a lot of third-party examples use '=='. What is the most correct use?
Side Question Answer
The helpful folks on the M/Monit team advise that "=" is an alias for "==" in the Monit configuration file.
I added the solution I found to my question above.
All, I'm trying to setup flask-mail to send notifications to my email when a user registers.
I'm getting no error messages from the script used to send the email, but nothing is actually being sent, or at least, nothing is being received.
Is there a log file which can show if an email was sent, rejected, or maybe if there was even a problem logging onto the server? How does on track this problem?
Any ideas here?
Flask-Email use smtplib which can set debug level: https://github.com/mattupstate/flask-mail/blob/master/flask_mail.py#L139. You can set it with MAIL_DEBUG = True or DEBUG = True. Also check that MAIL_SUPPRESS_SEND = False and TESTING = False.
With debug I can see in stdout mail progress: success, fail, recipients and etc.
See details: http://pythonhosted.org/Flask-Mail/#configuring-flask-mail.
tbicr has the most likely fix, check MAIL_SUPPRESS_SEND first.
What ended up burning me (being new to flask) is that when you instantiate your Mail() object, be sure it's after you've set your app.config values. The Mail() object doesn't go back and look at these values after the fact, so they will default to bad values. What's frustrating is that you won't see any errors when you try to send messages with the default/bad values. At least not as of my posting.
I know this post is from a while ago, but I just ran into the same issue. Like #tbicr mentioned make sure that app.testing is set to False. As it states in the Flask-Maildocs here:
"If the setting TESTING is set to True, emails will be suppressed. Calling send() on your messages will not result in any messages being actually sent."
This was exactly my problem. I implemented Google reCAPTCHA into one of my forms and the app.testing was set to True so I did not have to hit the reCAPTCHA box every time. By removing the app.testing or by setting it to False, the emails were able to be sent.