Previously mail was routed through production servers (and that worked mostly by accident, thanks to eqiad VMs being in 10.0.0.0/8). Now that we're in a different IP range we need our own mail routers.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T53494 Use Beta cluster as a true canary for code deployments (epic) | |||
| Open | None | T87220 Minimize infrastructure differences between Beta Cluster and production | |||
| Open | None | T196662 Set up LVS in beta like prod | |||
| Resolved | bd808 | T166396 Program 1 Outcome 4: VPS hosting | |||
| Resolved | None | T167293 Nova-network to Neutron migration | |||
| Duplicate | herron | T205158 Mail relays needed for VMs in eqiad1 | |||
| Resolved | herron | T41785 Create a Cloud VPS SMTP smarthost | |||
| Resolved | bd808 | T174618 Request creation of project-smtp VPS project | |||
| Resolved | herron | T206261 Routing RFC1918 private IP addresses to/from WMCS floating IPs |
Event Timeline
Comment Actions
Marking this as a blocker for eqiad1-r usage based on the comments at https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/462012/
Comment Actions
Am I the only one missing here why we can't just fix the firewall rule for the MX servers to allow the new range and migrate to T41785 later? This doesn't seem in-scope for the eqiad1 migration.
Comment Actions
It worked previously by accident (because eqiad vms are in 10.0.0.0/8 which is also the internal production range). Moving VMs out of that range is a feature rather than a bug (it gets us better security separation) and adding the new IP range to the prod MX server would backslide on the aim of getting better separation.
I don't feel all that strongly about this, but inasmuch as some folks on the SRE team care about it and have also volunteered to build the new MX servers, it's fine with me :)