Physical movement of machines preparation

[Regina Obe]

> On Mon, Sep 15, 2025 at 10:47:36AM -0400, Regina Obe wrote:
> 
> > 1) Containerize current osgeo6 (which is already done on osgeo9)
> 
> I understand this step is not completed until the IP (or hostnames?) that
> currently points to osgeo6 start pointing to the new containerized machine.
> 

We are changing the ip to what is currently in the network forward in osgeo9 but keeping the host name.
I think we'd want to keep the current osgeo6 ip  cause it would be hard to reach it except thru the private ip (which requires you be connected to OSUOSL VPN) if we try to switch 
and we already allocated an extra ip for osgeo9 for this purpose.


> I actually wonder what "containerize" really meant, other than having the
> ability to have a container that can be fully accessed via its own IP address
> (currently done with network forward which is one of the possible options, is
> my understanding).

There are two kinds of things you can have in lxd.  Originally lxd when we started only supported containers.
You can have a VM or an OS container.  Container is lighter weight than VM cause it doesn't have it's own kernel and settings on it are really quotas than true settings.
e.g. you allocate disk or memory or cpu it’s a quota. So to change it you just change the quota.  No need to even restart the container to do that, where as changing VM disk and memory requires changing config, doing the usual resize disk etc and restarting the VM.

VM emulates everything.  We used lxd-migrate tool to replicate osgeo6 to a container.

Lxd-migrate is part of lxd source code https://github.com/canonical/lxd/tree/main/lxd-migrate  and they provide the binary as part of their release cycle.  It is used both for containerization and virtualization of a Physical/VM

Converting a physical to a VM is trickier as you got to have more stuff configured and I think even have the original install media since it tries to emulate everything.
For most cases unless you are trying to emulate a GUI or a non-Linux OS, OS containers are sufficient and much simpler to manage.

To do say FreeBSD, Windows, or Mac you would need a VM.

VM has one big advantage aside from supporting more OS in that you can nest it more.
E.g. for Bas's cowbuilder Debian testing to emulate the 32-bit issues on PostGIS he was running into, I had to create a VM to run cowbuilder in.
Cause I think cowbuilder tries to create another QEMU of 32-bit or some such thing.  So in theory you can emulate a 32-bit within a VM on lxd.

VMs in LXD leverages QEMU under the hood but allows you to manage the VM with the same tools as you manage containers.
So they are referred to as instances if you are talking about both VMS and Containers under LXD.
QEMU under LXD has a deficiency or at least it used to in that a 64-bit host can't create a 32-bit VM where as with raw QEMU you can do that.
But the cowbuilder thing, I was able to create a 32-bit VM under a 64-bit lxd vm. Sounds crazy but it works.

> 
> > 2) Confirm all is working on osgeo9 (we did not test the MTA too much
> > but we did test mailing lists), and sending mail via new osgeo6
> 
> We'll need other testing ONCE the IP (or hostnames) are repointed.
> 
> > 3) Production Switch to containerized osgeo6 on osgeo9
> 
> Is this the point in which you would assign 140.211.15.3 to osgeo9 ?
> Or do you think we should ONLY point the hostnames mail.osgeo.org and
> lists.osgeo.org and tilecache.org and www.tilecache.org ?)
> 

As mentioned above the plan is to only repoint the host name

> > 4) shut off osgeo6, make sure everything is still working
> 
> I'll not think about the next steps until the previous steps (up to "production
> switch") are clear.
> 
> > DNS wise I think our downtime is pretty low.  I've noticed it only takes like
> an hour or so.
> 
> The mail.osgeo.org and lists.osgeo.org DNS records have a TTL of
> 300 seconds (5 minutes), way less than an hour. And we can now change them
> easily via Ansible, if we want, see:
> 
>   https://gitea.osgeo.org/sac/ansible-
> deployment/src/branch/master/deployment/roles/dns-
> records/tasks/mail.yml
>   https://gitea.osgeo.org/sac/ansible-
> deployment/src/branch/master/deployment/roles/dns-records/tasks/mx.yml
> 
> > Though we can't account for dns servers caching for longer than they should
> or client pcs caching.
> 
> 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.


> Should we configure the current mail server to forward ALL incoming mail to
> the new mail server, thus keeping 2 separate IP addresses and 2 hostnames,
> and refuse to  work as a mail submission agent (block all outgoing mail) ?
> 
That's a good idea. Yes we should probably do that.

> Or do we keep the SAME IP and thus the same DNS records while just
> assigning them to osgeo9 instead of osgeo6 ?
> 
> --strk;
> 
>   Libre GIS consultant/developer 🎺
>   https://strk.kbt.io/services.html

No we do not keep the same ip as mentioned or at least that was not the plan.
As to whether it's better to do that perhaps.