Home Lab Alerts with a Legacy Google Apps Domain and Synology Notifications

I run a handful of Synology NAS storage ararys as part of my home lab collection. Some of them store files while others run virtual machines. During their initial configuration process, I also set up an alerting account on my Legacy Free Google Apps domain, wahlnetwork.com, so that I had a highly restricted account with the singular goal of allowing alerts to be sent via SMTP relay. This has been working for years.

Upon returning from a trip to Europe, I noticed that NAS2 – which is my Synology DS2411+ used to run the majority set of virtual machines – had a drive failure in bay 8.

nas2-disk-alert

I was curious why I had not seen any alerts on this, so I popped into my alert account and saw this email:

1failed-sign-in-attempt

I’ve seen this error before and figured I’d just need to pass a captcha or some other security hoop. But, I didn’t want to assume that my storage array was to blame. To validate that it was the Synology triggering the sign-in error, I requested a test email. The Synology interface immediately responded with a 534 error, which essentially means that authentication failed.

1test-email-failed

Hmm. Perhaps I could simply white list my home’s IP address and avoid using user credentials?

Google Apps SMTP Relay

Google Apps does support IP address white listing for SMTP Relay. In fact, there’s even a custom FQDN for it: smtp-relay.gmail.com. As per Google:

[the service] is used to send mail from your organization by authenticating with the IP address(s). You can send messages to anyone inside or outside of your domain. (source)

Unfortunately, this feature is not available to Legacy Free users. This means that my options are limited to the Gmail SMTP server or the Restricted Gmail SMTP Server. Eww!

Authorizing the Synology Device

This is when I realized that there was another option available within Synology that I don’t recall being in DSM years ago: device authorization. This should end up being a one-time process to authorize the Synology to send alerts on behalf of the account. Sounds good to me!

To begin, head to Control Panel > Notification > Email. Enable Email alerts and select the Gmail service provider. Then, press the Log in to Gmail button.

1synology-email-setup

A pop-up window will present itself stating the permissions that Synology is requesting. Review them and click Allow to continue.

1auth-synology-email

To validate that the action is being taken on the correct address, an additional window will present itself detailing the device details. In my case, it’s simply a box named NAS2. Click Agree to continue.

1synology-alert-agree

Sending an additional test alert results in success. I can see the alert in my inbox.

1email-test-successful

Managing the Google Apps Authorization

If you would like to review or revoke access to your Google Apps account, head to Google Apps > Users. Select the User that was used to authorize Synology. Then scroll down to the Security > Authorized Access section.

1security-page-gmail

You can also see this by using the Google Accounts page for the specific user and heading to Sign-in & Security > Connected Apps & Sites. I just prefer to manage everything from the parent organization for simplicity sake.

Centralizing Notifications with CMS

Using an authorized Gmail account is also handy for those looking to use the Central Management System (CMS). Rather than configuring notifications on each Synology device, you would just configure it once on the CMS Host. In my case, NAS2 is the CMS Host and NAS1, NAS3, and NAS4 are feeding notifications upstream.

To do this, edit (or create) the CMS Policy for your devices by editing the Notifications > CMS setting and checking the Send notifications to CMS Host box.

cms-rule-notifications

Alternatively, you can configure it on a device directly. Browse to Control Panel > CMS and check the Enable centralized notifications box on each Synology device in your environment. Alerts will be forwarded along by the CMS Host using the notification preferences configured.

cms-email

That’s it! I realize that I’m a bit behind the curve on embracing these new notification options. It’s a great highlight as to why “best practices” fade over time, and why it’s always good to review the available options when making changes to a design.