Two enhancement options for Integration Alert?

Percona Monitoring and Management (PMM) PMM 2.x
1

Hi All,

Are these two enhancement options for current PMM2?

  1. insecure_skip_verify: to skip valid SSL cert;or use and DNS name to access email server;
  2. have a way to setup smtp_require_tls in PMM webUI

The following is the case why I ask this question.

In my environment with network firewall, we have VLAN to sperated differenet network. So, the database servers and PMM server can’t access email service directly. So, I have to setiup a forward server in my networks and create a IPTABLES forword rules.
Let’s say:
Server A: PMM server
Server B: Forword server1
Server C: Forword server2
Server D: Email server

So, typically, A sends email to B; and B transfers to C; and then, C transfers to D; In fiannly, D is the mail server, so I can get the email of any problem.

Laster friday, 12-10, our email system upgrade from MS exchange to a new vendor. The major changes is the new system only have accept encrypted connection. So, when PMM server send email, the alertmanager reports “*smtp.plainauth auth: unencrypted connection”.

After researches, I updated “smtp_require_tls” to “true” in /etc/alertmanager.yml and restarted alertmanager. It shows “x509 cannot validate certificate for it doesnt contain any ip sans” in log files.

After researches again, following x509: cannot validate certificate for <ipaddress> because it doesn't contain any IP SANs · Issue #1654 · prometheus/prometheus · GitHub, the first reply, I modified “server address” to a email server name, and added a DNS entry to “/etc/hosts”. it works. And the PMM version is 2.23.

The problem is: if I upgraded PMM2 docker image, the DNS and smtp_require_tls would be lost.

Thanks,
Dillon

2

The checkbox for “Require TLS” has been implemented as of 2.25.0! You can get that one right now with an upgrade. I think I understand the DNS issue in that you have two relay servers so the name (or IP) you’re calling the Server A with does not match the certificate issued by Server D so error? If that’s the problem you have a few choices:

  1. make the name match as you have using /etc/hosts (which you can make survivable with a docker parameter (--add-host ServerD.company.com:<ip_address_of_server_A> added to your docker run)
  2. you can edit the /etc/alertmanager.yml file inside the container and turn off verification by adding insecure_skip_verify: true. This will not surivive container upgrade though. As far as I know there’s no plan to implement it in the UI though so maybe put in a feature improvement in our jira if you think that’s somethign that should be there.
  3. Turn Servers B and C into actual SMTP smart relays but that may be one more thing to maintain vs simple iptables rules…

Hope this helps!

2 Likes
3

Steve,

Thanks for advise. Per you explanation, I prefer the first option… It looks like better in our environment.

Thanks,
Dillon

1 Like