<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 15, 2025 at 8:25 PM 'Sandro Santilli' via Sac <<a href="mailto:sac@lists.osgeo.org" target="_blank">sac@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Sep 15, 2025 at 05:10:39PM -0400, Regina Obe wrote:<br>
> <br>
> We are changing the ip to what is currently in the network forward in<br>
> osgeo9 but keeping the host name.<br>
<br>
Then, when ready, we should re-point all these A records:<br>
<br>
- <a href="http://lists.osgeo.org" rel="noreferrer" target="_blank">lists.osgeo.org</a><br>
- <a href="http://mail.osgeo.org" rel="noreferrer" target="_blank">mail.osgeo.org</a><br>
- (*.)<a href="http://tilecache.osgeo.org" rel="noreferrer" target="_blank">tilecache.osgeo.org</a> [ shall we move this ? ]<br></blockquote><div><br></div><div>tilechache, together with mapserver were on osgeo6, mapserver has been taken care of</div><div><a href="https://trac.osgeo.org/osgeo/ticket/3405" target="_blank">https://trac.osgeo.org/osgeo/ticket/3405</a></div><div>tilecache is on osgeo9 osgeo-buster.</div><div>What to do with it can be decided later:</div><div><a href="https://trac.osgeo.org/osgeo/ticket/3407" target="_blank">https://trac.osgeo.org/osgeo/ticket/3407</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- <a href="http://drone.osgeo.org" rel="noreferrer" target="_blank">drone.osgeo.org</a> [ shall we drop this ? ]<br></blockquote><div><br></div><div>That site wasn't even enabled.</div><div> <a href="https://gitea.osgeo.org/sac/osgeo9/wiki/mailserver-container#sites-available-cleanup" target="_blank">https://gitea.osgeo.org/sac/osgeo9/wiki/mailserver-container#sites-available-cleanup</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And update the SPF records to include the new IP (this could be already done now).<br>
<br>
> > I actually wonder what "containerize" really meant<br>
> ><br>
> Lxd-migrate is part of lxd source code <a href="https://github.com/canonical/lxd/tree/main/lxd-migrate" rel="noreferrer" target="_blank">https://github.com/canonical/lxd/tree/main/lxd-migrate</a><br>
<br>
What I meant was: are we supposed to have an exact copy of all data ?<br>
<br>
I think the answer is YES, but from the time lxd-migrate was run the<br>
data on the machines started diverging. How are we going to deal with that ?<br>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I understood there's an rsync script but that script does NOT copy ALL<br>
the data, just a number of selected subdirectories, </blockquote><div><br></div><div>ture</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and the script itself<br>
is run from within the new machine, making it impossible to copy (say)<br>
the /etc/cron* directories w/out removing the script.<br></blockquote><div> </div><div>It's already been copied, and yes I have modified it, </div><div>- commented out the mailman_stats.sh </div><div>- added the rsync-osgeo6.sh <br></div><div>And when we do the movement, when I remove the rsync-osgeo6.sh I will uncomment the mailman_stats.sh </div><div><br></div><div>For other configurations like mailman<br>```</div><div>perl -pi -e 's/staging\.//' /etc/mailman/mm_cfg.py</div><div>```</div><div><br></div><div>Fix lists url if needed: which catch the name on mm_cfg.py</div><div>Fix lists permissions if needed. (which have been fixed on osgeo6 and its not needed)</div><div><br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > If we cannot account for DNS timing, how do we deal with mail queues ?<br>
> <br>
> 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.<br>
> So I don't see this as being an issue except for making sure osgeo6 queue is clear before we switch over.<br>
<br>
We'll need to make sure mail directed at the old IP get a bounce,<br>
to get the retry (hoping the retry will be to the new IP).<br>
<br>
As per OUR queues, at the time of writing <a href="http://mail.osgeo.org" rel="noreferrer" target="_blank">mail.osgeo.org</a> has 2114 queued messages.<br>
We need to plan how to clear that queue.<br>
</blockquote><div><br></div><div>Looks like today it has only 219:</div><div><span style="font-family:monospace">root@osgeo6:/home/cvvergara# postqueue -j | wc -l<br>219</span></div><div><br></div><div>And yes, I dont deny that there will be a disruption on the mail service, a proper announcement is needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
--strk; <br>
<br>
Libre GIS consultant/developer 🎺<br>
<a href="https://strk.kbt.io/services.html" rel="noreferrer" target="_blank">https://strk.kbt.io/services.html</a><br>
</blockquote></div></div>
</div>