Edit: It seems that when sending via cron, sendmail isn't using the 'from' domain set in the config, and so the message is being rejected by SES as an unverified domain. So the question is now, why isn't sendmail using these settings in the config when running from cron?
This is a bigger issue than this question, but this part seems to sum it up completely.
I have a number of ec2 instances. These use sendmail to relay messages through SES.
There are a number of bash scripts on these servers that email reports when the script has completed.
If I manually run one of these scripts, the email successfully sends. However, if run by cron, I see "dsn=5.0.0, stat=Service unavailable" in the maillog.
Sendmail is accepting the message, but relaying it through SES generates this error.
I know the environment is different between cron and an interactive user, but I can't see how just a part of this sending process could fail in this case.
Any suggestions would be much appreciated. Please let me know if any more info would be helpful.
Thanks
Related
I have been following the documentation in every step, and I didn't face any errors. Configured, deployed and made a subscription to hello/world topic just as the documentation detailed. However, when I arrived at the testing step here: https://docs.aws.amazon.com/greengrass/latest/developerguide/lambda-check.html
No messages were showing up on the IoT console (subscription view hello/world)! I am using Greengrass core daemon which runs on my Ubuntu machine, it is active and listens to port 8000. I don't think there is anything wrong with my local device because the group was deployed successfully and because I see the communications going both ways on Wireshark.
I have these logs on my machine: /home/##/Desktop/greengrass/ggc/var/log/system/runtime.log:
[2019-09-28T06:57:42.492-07:00][INFO]-===========================================
[2019-09-28T06:57:42.492-07:00][INFO]-Greengrass Version: 1.9.3-RC3
[2019-09-28T06:57:42.492-07:00][INFO]-Greengrass Root: /home/##/Desktop/greengrass
[2019-09-28T06:57:42.492-07:00][INFO]-Greengrass Write Directory: /home/##/Desktop/greengrass/ggc
[2019-09-28T06:57:42.492-07:00][INFO]-Group File Directory: /home/##/Desktop/greengrass/ggc/deployment/group
[2019-09-28T06:57:42.492-07:00][INFO]-Default Lambda UID: 122
[2019-09-28T06:57:42.492-07:00][INFO]-Default Lambda GID: 127
[2019-09-28T06:57:42.492-07:00][INFO]-===========================================
[2019-09-28T06:57:42.492-07:00][INFO]-The current core is using the AWS IoT certificates with fingerprint. {"fingerprint": "90##4d"}
[2019-09-28T06:57:42.492-07:00][INFO]-Will persist worker process info. {"dir": "/home/##/Desktop/greengrass/ggc/ggc/core/var/worker/processes"}
[2019-09-28T06:57:42.493-07:00][INFO]-Will persist worker process info. {"dir": "/home/##/Desktop/greengrass/ggc/ggc/core/var/worker/processes"}
[2019-09-28T06:57:42.494-07:00][INFO]-No proxy URL found.
[2019-09-28T06:57:42.495-07:00][INFO]-Started Deployment Agent to listen for updates. [2019-09-28T06:57:42.495-07:00][INFO]-Connecting with MQTT. {"endpoint": "a6##ws-ats.iot.us-east-2.amazonaws.com:8883", "clientId": "simulators_gg_Core"}
[2019-09-28T06:57:42.497-07:00][INFO]-The current core is using the AWS IoT certificates with fingerprint. {"fingerprint": "90##4d"}
[2019-09-28T06:57:42.685-07:00][INFO]-MQTT connection successful. {"attemptId": "GVko", "clientId": "simulators_gg_Core"}
[2019-09-28T06:57:42.685-07:00][INFO]-MQTT connection established. {"endpoint": "a6##ws-ats.iot.us-east-2.amazonaws.com:8883", "clientId": "simulators_gg_Core"}
[2019-09-28T06:57:42.685-07:00][INFO]-MQTT connection connected. Start subscribing. {"clientId": "simulators_gg_Core"}
[2019-09-28T06:57:42.685-07:00][INFO]-Deployment agent connected to cloud.
[2019-09-28T06:57:42.685-07:00][INFO]-Start subscribing. {"numOfTopics": 2, "clientId": "simulators_gg_Core"}
[2019-09-28T06:57:42.685-07:00][INFO]-Trying to subscribe to topic $aws/things/simulators_gg_Core-gda/shadow/update/delta
[2019-09-28T06:57:42.727-07:00][INFO]-Trying to subscribe to topic $aws/things/simulators_gg_Core-gda/shadow/get/accepted
[2019-09-28T06:57:42.814-07:00][INFO]-All topics subscribed. {"clientId": "simulators_gg_Core"}
[2019-09-28T06:58:57.888-07:00][INFO]-Daemon received signal: terminated. [2019-09-28T06:58:57.888-07:00][INFO]-Shutting down daemon.
[2019-09-28T06:58:57.888-07:00][INFO]-Stopping all workers.
[2019-09-28T06:58:57.888-07:00][INFO]-Lifecycle manager is stopped.
[2019-09-28T06:58:57.888-07:00][INFO]-IPC server stopped.
/home/##/Desktop/greengrass/ggc/var/log/system/localwatch/localwatch.log:
[2019-09-28T06:57:42.491-07:00][DEBUG]-will keep the log files for the following lambdas {"readingPath": "/home/##/Desktop/greengrass/ggc/var/log/user", "lambdas": "map[]"}
[2019-09-28T06:57:42.492-07:00][WARN]-failed to list the user log directory {"path": "/home/##/Desktop/greengrass/ggc/var/log/user"}
Thanks in advance.
I had a similar issue on another platform (Jetson Nano). I could not get a response after going through the AWS instructions for setting up a simple Lambda using IOT Greengrass. In my search for answers I discovered that AWS has a qualification test script for any device you connect.
It goes through an automated process of deploying and testing a lambda function(as well as other functionality) and reports results for each step and docs provide troubleshooting info for failures.
By going through those tests I was able to narrow down the issues with my setup, installation, and configuration. The testing docs give pointers to troubleshoot test results. Here is a link to the test: https://docs.aws.amazon.com/greengrass/latest/developerguide/device-tester-for-greengrass-ug.html
If you follow the 'Next Topic' links, it will take you through the complete test. Let me warn you that its extensive, and will take some time, but for me it gave a lot of detailed insight that a hello world does not.
I want to get notifications by email for errors on my google cloud service.
It seemed pretty easy to setup. I just hit turn on notifications in Error Reporting in Stackdriver for all services (I only have 1 service).
I created some errors for testing, but didnt receive any emails.
Went into alert policy and profiles and added email notification as a channel. Still not notifications via email.
What am I doing wrong?
I think the best way to check if the notification is actually being sent is to post a test error message manually to the error reporting API.
First, verify that error notifications are available for the project, and then, run the following command on your cloud shell:
gcloud beta error-reporting events report --verbosity=debug --service Manual --service-version test1 \
--message "java.lang.TestError: msg
at com.example.TestClass.test(TestClass.java:51)
at com.example.AnotherClass(AnotherClass.java:25)"
You should receive an email from StackdriverNotifications-noreply#google.com
If you receive the notification for the test, your other errors might be misconfigured. If you don't receive it, then you might need to verify that the noreply address is not being blocked by your provider/filters.
Setting up Meteor to use "out of the box" AWS SES is simple, and one can use native Meteor "Email" methods without modification.
Steps to implement this can be found here. Thanks to Brian
Shamblen for putting together a detailed answer.
But one caveat with the "out of the box" SES is you need to both verify the sender and receiver email address.
To remedy this, you can put in a request with AWS SES for what they call, Production Access.
And further, according to Brian Shamblen,
The process to get production access is rather complicated. One will
need to handle bounce and complaint notifications from SES and prevent
messages from being sent to those addresses in the future.
Question
What is the Meteor code involved in handling bounce and complaint notifications from SES and prevent messages from being sent to those addresses in the future?
EDIT: Made modifications to question for clarity.
Requesting production access is fairly straightforward. You just need to contact them and they usually give it to you in a couple of hours.
Information about the process is here: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html
Load up the URL : http://aws.amazon.com/ses/fullaccessrequest/ and let them know what you will be sending via Emails, for example if you will be sending transaction based email (verification of a transaction, etc)
With production access you can either send email from:
A specific verified email address, where you will be asked to click a link to an email sent to that address to verify you own it
Any email under an entire domain. Under this process you prove you own the domain by editing its DNS records to contain a 'key'.
Most use cases are covered under production access, they typically give you 2000 emails a day and rate limit emails to 5/sec (they queue them so the maximum send rate is 5/sec). If you need more than this you can contact them to raise this additionally.
The process of verification is to stop people quickly creating AWS accounts to mass-spam users. If they allowed this straight-off then AWS IPs would be looked at as spam by other email providers.
For bounce notifications, SES tracks these, and you have to make sure that you don't get an above average bounce rate. Typically these would come from sending unsolicited email, which I wouldn't advise sending via SES.
Production access is only approved by the AWS team. Wait a bit and they should easily give you 2.000 emails/day for free.
As per bounces-unsubscribes... You'll need to have the SES API notify you of each email address which has been 'marked' with such status.
You should store all those email addresses somewhere and tell your app not to send them ANYTHING else in the future.
Iam trying to send a message to activemq using pythons stompclient.
https://bitbucket.org/hozn/stompclient/wiki/User%20Documentation
If there is a better library for this Im open to suggestions.
If i change to ip or port it will fail to connect so im assuming that the connection is working. There are no errors when I run this code its just that I see no messages on the queue. I think the destination path is possibly where it is failing the PhysicalName of the activemq queue is in this pattern 'abc.queue_name'.
I've tried the following destinations
/queue/abc/queue_name
/queue/abc.queue_name
abc.queue_name
Any suggestions are greatly appreciated.
Thanks
from stompclient import PublishClient
client = PublishClient('IP', 53680)
response = client.connect('defaultPassword', 'defaultUser')
reponse1 = client.send('/queue/abc/queue_name', 'bla')
time.sleep(5)
Have you checked the webconsole to see if your Queue was created by the send?
You should also try adding a request id onto the send and waiting for a response, this will ensure that the broker has enough time to get the sent data before you client code disconnects.
You might also want to check the Broker logs to see if any errors are logged or any security warnings in case the user doesn't have publish rights.
Added this property to the activemq.xml file and im now seeing messages on the queue via the web console.
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/>
I have a Django project that needs to send out around 600 emails. I have Celery set up and it works, for the most part. I have the Django project set up to use my Google Apps (Business version -- ie: paid for) email account as the sending account. For testing purposes, I have every email sent to me -- not to the client.
The issue I am having is that Celery seems to randomly skip people in the list. When I start the process of sending all 600 emails, Celery works away, sending emails (I can see them show up in my inbox) but I only receive a total of about 420 emails. When Celery finishes, there are still 180 or so people that need the email. If I click "send emails" again with ONLY the remaining 180 people, it will finish the job and, at the end of two attempts, will have sent emails to all 600 people.
Why would Celery be skipping people?
Yes, you will get those gmail errors and it's not particularly predictable.
You could just use django-mailer instead -- I do, and deal with those gmail connection errors by letting django-mailer automatically retry the failed sending attempts until they succeed.
Check out this SO question for more folks suggesting you just use django-mailer vs celery for mail.
Advice on Python/Django and message queues