Easy Email-relay setup with Debian and Postfix using your Gmail account

When your homelab suddenly becomes critical, isn’t it nice to get notifications if something happens? Indeed, and it’s nice to have an SMTP-host in your network that can relay all email without tinkering with your Google account every single time you need to configure email in your apps and services.

Starting with a Debian 11 LXC (from the templates in Proxmox) you only need to make a few steps to have Postfix working

First you need the sasl2-libs

# apt install libsasl2-modules

Add the following to /etc/postfix/main.cf

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
inet_interfaces = all

Regarding inet_interfaces it may be set to «loopback-only» by default, thus not accepting incoming traffic on port 25. If you have multiple ports/IPs and want different config for these – check Postfix documentation.

Add the Verisign Certificate Authority to Postfix’s CA file:

# tee -a will append contents to file if file already exists
cat /etc/ssl/certs/VeriSign_Universal_Root_Certification_Authority.pem | tee -a /etc/postfix/cacert.pem

Next you need to generate a Gmail App Password for use with the sasl_password file. Go to App Passwords on your Google Security Tab and create one. Select “Other (Custom name)” and copy the 16 characters.

Then edit /etc/postfix/sasl_password and add the following info

[smtp.gmail.com]:587    USERNAME@gmail.com:APP_PASSWORD

Replace USERNAME with your gmail username and APP_PASSWORD with the 16 characters you just copied (remove any spaces!)

Set the correct permissions on the file

chmod 400 /etc/postfix/sasl_passwd

Use Postmap to generate the sasl_passwd.db file

/usr/sbin/postmap sasl_passwd

Restart the Postfix service

/etc/init.d/postfix reload

If you did all steps correctly you should be able to send email from this LXC without issues

echo "Subject: Test mail from postfix" | sendmail -v USERNAME@gmail.com

Verify the logs and see if you did everything correctly

root@Postfix:/etc/postfix# tail -f /var/log/mail.log 
May  3 06:31:23 Postfix postfix/postfix-script[1279]: starting the Postfix mail system
May  3 06:31:23 Postfix postfix/master[1281]: daemon started -- version 3.5.6, configuration /etc/postfix
May  3 06:32:11 Postfix postfix/pickup[1283]: CCFC45E1B: uid=0 from=<root>
May  3 06:32:11 Postfix postfix/cleanup[1296]: CCFC45E1B: message-id=20220503063211.CCFC45E1B@Postfix.localdomain
May  3 06:32:11 Postfix postfix/qmgr[1284]: CCFC45E1B: from=<root@Postfix.localdomain>, size=268, nrcpt=1 (queue active)
May  3 06:32:13 Postfix postfix/smtp[1298]: CCFC45E1B: to=<USERNAME@gmail.com>, relay=smtp.gmail.com[]:587, delay=7, delays=5.3/0.04/0.5/1.1, dsn=2.0.0, status=sent (250 2.0.0 OK  1651559533 n21-20020a2e86d5000000b0024cac53a82csm1248338ljj.0 – gsmtp)

VMware and PowerCLI

Sooner or later you may have to do some «serious work» outside of the vCenter GUI or vCenter client. PowerCLI on a Windows machine is the obvious choice here. I’m in the middle of upgrading an ESXi 5.0 cluster with a non-SSO based vCenter to a new 5.5 cluster with a SSO-capable vCenter 5.5 server. Downtime is critical, and migration from one cluster to a new when using dvSwitches does not work without some tinkering.

Doing some reading I’ve found that one way to do this is to create old school vSwitches with all the needed VLAN’s and change the Network on all VMs from dvSwitches to vSwitches. Testing show a packet loss of 1-2 packets, which is acceptable. The main issue here is creating the new vSwitches. No biggie if you have a SOHO lab, but with 12 servers and 40 VLANs we’re talking click-click-click if you’re using a GUI.

First of all – get PowerCLI installed and configured



Check the references for PowerCLI and Virtual Switches


Then read these http://www.mikelaverick.com/2014/01/back-to-basics-configuring-standard-vswitch-with-powercli-part-three-of-three/ as well as http://www.gabesvirtualworld.com/migrating-distributed-vswitch-to-new-vcenter/ and you should be ready to go!

Another issue here is naturally if you use EVC in you cluster, and maybe stepped up a notch if the new cluster have more recent hardware. We’re in this situation, going from Dell 11G to 12G/13G servers, and we do have to reboot the machines anyhow. To get it somewhat smooth I intend to fill one of the ESXi 5.0 servers with as many VMs as common sense tells me to, remove it from the old vCenter and add it to the new SSO-enabled vCenter. The VMs on this particular server will be shut down and then migrated onto the new cluster, and probably upgraded with the newer hardware version/VMwareTools.