I did NOT install an local MTA because the heirloom-mailx already is able to speak to an external SMTP-Server. Therefore I edited the configuration in ~/etc/mail.rc from site-user with additional parameters:
set smtp=smtp://mx.example.com
set from="checkmk@example.com"
Testing:
OMD[mysite]:~$ echo "content" | mail -s test-subject harry.hirsch@example.com
This does send an email as expected, but checkmk always complains about missing sendmail.
this seems to be ignored or do i need to configure additional parameter in CMK?
It is very easy. CMK expects the command “/usr/sbin/sendmail” to exists for the default mail notification plugin.
You can also place your own symlink to another command inside the site as “~/local/bin/sendmail”. But it needs to be “sendmail” as command.
If it should be that simple than i wonder why it is stated differently in documentation:
You can test the sending of emails easily with the mail command on the command line. Because there are numerous different implementations for this command under Linux, for standardization Checkmk provides the version from the Heirloom mailx project directly in the site user’s search path (as ~/bin/mail ). The corresponding configuration file is ~/etc/mail.rc . The best way to test this is as a site user, since the notification scripts will later run with the same permissions.
And exactly whith that command i can send email without any need for additional installed software. So it could be much easier than depending on “sendmail” - checkmk delivers all necessary binaries! So my question is, why does checkmk does not use this tool when correctly configured?
This is only to test if your system can send mail.
If you read the mentioned manual article correctly you will see that this is only to verify that your system MTA is working as expected.
From the start of the article.
For the successful sending of emails, your Checkmk server must
have a functioning SMTP-server configuration. Depending on your
Linux distribution, this could utilize, for example, Postfix, Qmail,
Exim, or Nullmailer. The configuration will be implemented with
your Linux distribution’s resources.
So you say, that Checkmk provides this extra mailprogram just to make sure you can test your locally installed sendmail program. That seems very odd to me.
So i would need a complete setup of Postfix or other additional software (MTA) on every instance, make sure that everything is really secure and can not be used for bad things just to provide a solution to send mail from MUA, if OMD already delivers all necessary parts in its distribution and only would need to use this toolset?
How is this problem solved in containerized environments where i do not have the possibility to install such tools?
I’m not sure but I have the impression that ASCII mail notifications require /usr/sbin/sendmail while HTML mail notifications do not because that notification plugin uses the Python smtplib.
You don’t need a complete MTA setup. The docker container of CMK is using nullmailer that is also providing the /usr/sbin/sendmail binary.
That’s all what you need.
Only if you select “Enable synchronous delivery via SMTP” inside the notification rule.
Code from the mail notification plugin.
def send_mail(message: Message, target: str, from_address: str, context: dict[str, str]) -> int:
if "PARAMETER_SMTP_PORT" in context:
return send_mail_smtp(message, MailString(target), MailString(from_address), context)
send_mail_sendmail(message, MailString(target), MailString(from_address))
sys.stdout.write("Spooled mail to local mail transmission agent\n")
return 0
spooky: Four different methods just to deliver an email, where one solution is just for testing purposes and is never used by checkmk itself.
Why is this not streamlined to one simple fully configurable and OS-independent solution?
e.g. the already delivered heirloom-mailx or python smtplib?
What solution can i choose to have a different smtp setup in checkmk than my local OS?
Local mails have to be send differently than mails from checkmk. Different FROM-Adress, different smtp-server, different authentication mechanisms.
Not spooky. We offer you the freedom to choose the MTA you prefer. Why would we re-invent the wheel and build or bundle an MTA in Checkmk, forcing you to use that one?
The one point that is valid here, is that for HTML mail we offer the above-mentioned “synchronous delivery”, which uses smtplib. That is currently the only place in Checkmk, that uses Python to send a mail. I cannot speak to why that is the case and if it will change at some point.
Checkmk by default sends mails from the address $SITE@$HOSTNAME, unless specified differently within Checkmk. So you can configure your MTA to e.g. rewrite the default mails sender, or just specify the appropriate sender address in Checkmk.
That is really awesome to have the freedom of choice here, but to be precise the ‘mail’-command is an MUA and relies on some MTA/MDA(eg. postfix, exim, nullmailer) to deliver the email with different protocols like SMTP or local queuing.
The ‘mail’-command needs still configuration for the how and where to deliver. So it should be the freedom of choice for MTA/MDA but it does not have to be a freedom of choice for MUA. This should be part and decision of CheckMK to be first best implemented and secondly most compatible. With the already delivered heirloom-mailx all that would easy be possible.
So to get to an point here. I followed the documentation where it explicitly states “when using the the existing hmail and its configuration file you are fine!”.
Can somebody please remove at least the hint to the configuration file from documentation when its is not relevant and misleading?
This is not correct. We never state, that “you are fine”. It clearly says two things:
The outlines steps are for testing.
You need to set up a proper MTA yourself or use the Checkmk Appliance.
I am having trouble to see how you got the impression, that the binary provided for testing would be used in production, as the section opens with For the successful sending of emails, your Checkmk server must have a functioning SMTP-server configuration.
Maybe you can elaborate, how exactly the wording is misleading?
The first thing is the wording testing itself. If i get a proposed test scenario including configuration hints, i will assume this testing will do everything exactly like the software itself does in production. Otherwise this test is useless, because it tells me nothing.
So i assume when configuring and testing with documented setup works - i’m fine!
Or do you create a windows binary for testing only when the production workload shoud run on linux or anything else than windows?
according #2: I have setup an external MTA(external Provider/Cloud/*) and i want to use that MTA with SMTP-protocol. Therefore i need a MUA on OS where CheckMK is installed. As already discussed i do not need a full MTA on CheckMK just to deliver Mails.
Why should i bloat a system with “MTA” when there are plenty useful MUA solution out there, which natively support SMTP-protocol. And - oh wait - you alerady deliver one of these solutions with CheckMK out-of-the-box. But: its for testing only. Everything else i need to do on my own and this is not even documented with a hint like ‘it works best when you install binary-xy, but you have the freedom of choice’
SMTP-Server is MTA? or MUA with possibility to use SMTP-Protocol against external server?
You let me the freedom to choose the method to get emails sent → My Intention: great that i can choose from everything that can speak SMTP to deliver my emails.
What does CheckMK really use? A hardcoded method to handover some text and meta-informations to another local binary. NOT SMTP. This binary(MUA) needs additional configuration to speak SMTP to another MTA to deliver the mails.
I do have a functioning SMTP-server, i configured the already included heirloom-mailx for SMTP and it works.
What did i miss in documentation except that i can not use a testing scenario for production workload? And that SMTP-protocol is not directly supported for notifications.
The whole setup could be much easier if CheckMK would use a self-provided MUA with configurable delivery options.
I vote for heirloom-mailx as this is already included, differently configurable in every site, directly supports SMPT eg. with S/MIME and TLS for compliance and already proposed for testing purposes.
I’ll bet there are just 3-4 changed lines of code needed to get SMTP email notification done better.
Okay, I see we have a different definition of testing, which is fine. I see what you intend to say, but in my experience oftentimes testing is done with a minimal viable approach. In this very case it only verifies, that you can talk to the external mail server successfully in a common setup.
Frankly, that is not true. There are plenty of tests that do not to everything exactly like the production use case and still provide a ton of value.
It is for the HTML mail notification method. You want to look for the “synchronous delivery” option.
I can see where you are coming from, but including a third party binary is rarely a good idea, especially if it is that easy to install the tool and create the necessary configuration yourself. As a monitoring tool, we have made this very experience more than once. It is not as convenient, I give you that, but it is more powerful, leaves more choices and reduces technical debt on our end (which leaves us more resources to improve Checkmk). After all, we come from a Linux background and the beauty of Linux is, that you can plug all these great projects together to built something amazing, rather than having every project trying to deliver all the peripheral software themselves, wasting tons of resources.