Mail service move (was: Physical movement of machines preparation)
Vicky Vergara
vicky at erosion.dev
Tue Sep 16 12:43:15 PDT 2025
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
> - 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
> And update the SPF records to include the new IP (this could be already
> done now).
>
> > > I actually wonder what "containerize" really meant
> > >
> > Lxd-migrate is part of lxd source code
> https://github.com/canonical/lxd/tree/main/lxd-migrate
>
> What I meant was: are we supposed to have an exact copy of all data ?
>
> I think the answer is YES, but from the time lxd-migrate was run the
> data on the machines started diverging. How are we going to deal with that
> ?
>
I understood there's an rsync script but that script does NOT copy ALL
> the data, just a number of selected subdirectories,
ture
> 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,
- 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
Fix lists permissions if needed. (which have been fixed on osgeo6 and its
not needed)
> > > If we cannot account for DNS timing, how do we deal with mail queues ?
> >
> > We don't. But as I recall I think mail servers are set to retry for
> like 72 hours by default if they get a bounce.
> > So I don't see this as being an issue except for making sure osgeo6
> queue is clear before we switch over.
>
> 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
And yes, I dont deny that there will be a disruption on the mail service, a
proper announcement is needed.
>
> --strk;
>
> Libre GIS consultant/developer 🎺
> https://strk.kbt.io/services.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20250916/8a901b39/attachment.htm>
More information about the Sac
mailing list