Mail service move (was: Physical movement of machines preparation)

[Sandro Santilli]

On Tue, Sep 16, 2025 at 01:43:15PM -0600, Vicky Vergara wrote:
> On Mon, Sep 15, 2025 at 8:25 PM 'Sandro Santilli' via Sac <
> sac at lists.osgeo.org> wrote:
> 
> > On Mon, Sep 15, 2025 at 05:10:39PM -0400, Regina Obe wrote:
> > >
> > > We are changing the ip to what is currently in the network forward in
> > > osgeo9 but keeping the host name.
> >
> > Then, when ready, we should re-point all these A records:
> >
> >   - lists.osgeo.org
> >   - mail.osgeo.org
> >   - (*.)tilecache.osgeo.org [ shall we move this ? ]
> >
> 
> tilechache, together with mapserver were on osgeo6, mapserver has been
> taken care of
> https://trac.osgeo.org/osgeo/ticket/3405
> tilecache is on osgeo9 osgeo-buster.
> What to do with it can be decided later:
> https://trac.osgeo.org/osgeo/ticket/3407

According to DNS tilecache is expected to be found on whatever host
has IP address 140.211.15.13, which is osgeo9, which proxies ports 80
and 443 to the "nginx" container. In turn, the "nginx" container
proxies requests for "tilecache.org" to the osgeo6-buster container,
so we can say that "tilecache" is on BOTH osgeo9-osgeo6-buster AND
osgeo9-nginx (if you rename the "osgeo6-buster" container you'd also
have to update the nginx proxy.

> >   - drone.osgeo.org [ shall we drop this ? ]
> That site wasn't even enabled.
> https://gitea.osgeo.org/sac/osgeo9/wiki/mailserver-container#sites-available-cleanup

I've dropped that DNS record already.

> > I understood there's an rsync script but that script does NOT copy ALL
> > the data, just a number of selected subdirectories,
> 
> true
> 
> > and the script itself
> > is run from within the new machine, making it impossible to copy (say)
> > the /etc/cron* directories w/out removing the script.
> 
> It's already been copied, and yes I have modified it,

Will it be overridden on next rsync run ?

> - commented out the mailman_stats.sh
> - added the rsync-osgeo6.sh
-
> And when we do the movement, when I remove the  rsync-osgeo6.sh  I will
> uncomment the mailman_stats.sh
> 
> For other configurations like mailman
> ```
> perl -pi -e 's/staging\.//' /etc/mailman/mm_cfg.py
> ```
> Fix lists url if needed: which catch the name on mm_cfg.py

This part I think we could do with Ansible, did you look at
https://gitea.osgeo.org/sac/ansible-deployment/pulls/79 ?
That PR makes it so that the new container is ALSO considered
a production server and thus will use the same default values
for the variables used for the configuration of the mail
and mailman servers. The mm_cfg.py file is deployed from a template
using those variables, see:

  https://gitea.osgeo.org/sac/ansible-deployment/src/branch/master/deployment/roles/list-server/templates/etc/mailman/mm_cfg.py.j2#L37

Default variables for the role:

  https://gitea.osgeo.org/sac/ansible-deployment/src/branch/master/deployment/roles/list-server/defaults/main/mailman.yml

> Fix lists permissions if needed. (which have been fixed on osgeo6 and its not needed)

This would be good to have in ansible too, eventually

> > We'll need to make sure mail directed at the old IP get a bounce,
> > to get the retry (hoping the retry will be to the new IP).
> >
> > As per OUR queues, at the time of writing mail.osgeo.org has 2114 queued
> > messages.
> > We need to plan how to clear that queue.
> 
> Looks like today it has only 219:
> root at osgeo6:/home/cvvergara# postqueue -j | wc -l
> 219

That's due to me working on removal of malicious mails,
see https://trac.osgeo.org/osgeo/ticket/3437
Right now there are 198 in the queue, so the fix seemed effective
( we're now refusing mail from <anyone>@service.<anything>.cn )

Among those 198 there are cases of recipient mailbox being full (even
in gmail), unroutable IP addresses or connection refused or hanging
for legit-looking domains like:
  - geospatialvision.com
  - geoaspects.com
  - geostellar.com
  - geologicsystems.com

Those could be real users having temporary difficulties

> And yes, I dont deny that there will be a disruption on the mail service,
> a proper announcement is needed.

Maybe we can reduce the disruption by moving one service at a time ?
For example, we could start with the Mail Submission Service by
registering a new DNS entry like msa.osgeo.org and ask users of the
service to use that to send mail ?

The mail submission service wiki page is here:
  https://wiki.osgeo.org/wiki/SAC:Message_Submission_Agent

Mail submission requires TLS connection thus a valid certificate,
right now we're asking to use "lists.osgeo.org" because at the time
of bringing up the service we didn't know we could have multi-name
certificates, today we can do better (and I've read about your
experiments with adding the "mail.osgeo.org" on that certificate....

Mail submission also requires proper SPF and DKIM records setup,
which we could start working on before moving all the rest
(easily done via Ansible)

--strk; 

  Libre GIS consultant/developer 🎺
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20250917/97ddd9bb/attachment.sig>